ArcherPoint Dynamics NAV Developer Digest - vol 77
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 1099 IRS reporting error in NAV 2013 R2 and NAV 2015:
Any client who is on 2013 thru 2015 might want to test their 1099 information (Report 10110 “Vendor 1099 Information”). It should match their old system (pre 2013).
Run any of the 1099 reports and they have peculiar calculation issues. When you run the reports in pre-2013R2, then run them in 2013 or above, you will get different numbers. For instance, one client reported a whopping $236,000 difference when comparing the results of using the same data on the different releases. 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, just compared the code. The issue seems to affect only certain vendors, perhaps due to only certain scenarios. For instance, some vendor’s totals were correct. On a few that were incorrect that I analyzed, one contained voids, which were not handled properly in the new code. One had several payments which were paying for invoices from 2 years prior, so that was odd, but not handled by the new code. At least, not the same as 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. Workaround 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-NA version. That Codeunit has only 2 functions, GetAppliedVendEntries and GetAppliedCustEntries. They are both messed up. These functions are called, not just for 1099 info, so this bug may cause many discrepancies in many areas of NAV. So, this workaround is a must for any
This issue is STILL present in the latest versions of 2015. I haven’t had time to vet this out in 2016 as it takes certain unique scenarios that do not exist in Cronus. But, we will soon have clients testing on 2016 and I will report back. My advice is: anytime you are upgrading (or new implementations) advise your clients to test the 1099 report. The balance should match to the penny, old app vs new.
Dan Sass an article on Important vs Urgent:
This blog provides a great perspective on an issue that many of us struggle with at times myself included.
Important means anything that will get you closer to your next milestone or goal (you’ve got those worked out, right?).
Urgent means anything that has a perceived (note the emphasis) importance to you or someone else, when in reality the world won’t end if you don’t get to it now, or even at all.
Here’s the rub, though. Doing the urgent stuff makes you feel good. They are the things you can put a tick next to in Wunderlist, Basecamp or Asana and say to yourself “Wow, I got 18 things done today!”.
Saurav Dhyani on error using the development environment:
If anyone has faced the error below:
While Trying to Export (with Delete) / Import Language Layer even on a standard Cronus NAV 2016/ 2015 NA Database.
The Error Message:
Internal Compiler Error. Error Code = 0000000d.
The Resolution: Need to Run Developer Environment as Administrator 🙂
If you are interested in NAV development, check out our collection of NAV Development Blogs.
For step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.
If you found this post useful, you might also be interested to read through our archive of the Dynamics NAV Developer Digest.