ArcherPoint Dynamics NAV Developer Digest – vol 61
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 on migrating Global 2 Dimensions data:
I have a customer wanting to move their Global 2 Dimensions and replace it with a new one (NAV 2009R2-large database). Has anyone done this?
Matt Traxinger: It's been a long time since I did it. I would suggest doing it in a test database first, and doing it on the SQL Server so that it (hopefully) executes faster. That will tell you how long it will take, whether it can be done in an evening or over the weekend, etc.
Rick Dill: Donna, I think there is a function to do what you are looking to do. The global dimensions are defined on the G/L Setup record. One of the functions on the G/L setup allows you to "Change Global Dimension". It basically lets you change the dimension you are defining as Global Dimension 2. While I have not "Done It" in a live database, I have worked with clients during go-live where they had changed their mind on what they wanted for the Global Dimensions and used this function to do so.
Response: Thanks for the input. The database is 37GB, and when I went to try this in the test database it said it would take until Dec 22 2015 to finish! We will try it again on the SQL Server and let it run to see how long it will take. Just wanted to see if there might be better way.
Reporting tips from the team:
Rajasekhar Yedamakanti: Reporting Tip: When upgrading the reports from classic to RDLC to maintain alignment, width, and height of the controls, we have to divide the value in classic with 1000 and place the value for RDLC controls. For example, if we have Ypos in classic as 1269 then in RDLC we have to put 1.269cm for the Top in the Location of the control properties
Matt Traxinger: Reporting Tip: To create a data model that is easier to read and understand, you can insert your data into a temporary table. Temporary tables do not have to be licensed. That means you don't have to repurpose fields in existing tables. You can create your own table that combines everything into a nice, neat package. This will save you headaches on your layout too.
Suresh Kulla on redirecting pages of the same report to different trays of the printer:
Is there a way to redirect different pages of the same report to various trays of the printer (the NAV version is 2013 R2)?
Michael Heydasch: Our client required the remittance report to print from a different printer tray. No big deal, really, we just created a separate report for check remittance detail, configured the correct tray on the 2nd report, and called the 2nd report from the first report. That way the checks printed from one tray and the remittance report from a different tray automatically.
Question on standard cost without creating a revaluation journal:
Question: A company has a situation where we strongly suspect a user rolled the standard cost without creating a revaluation journal (he has since left the company so the proper flogging for this transgression could be carried out). So, five months later, they have values that seem to be stuck in WIP and several inventory interim accounts. They even have the ubiquitous 'zero quantity on hand but negative value' item.
I look to my manufacturing experts for any possible help for these kind folks. No back posting to the fateful February date when the costs were improperly rolled would be allowed. Would it help to restate the standard cost and properly run the revaluation journal as of today? I suspect they have already consumed or sold the un-revalued entries at this point. They are on a 5.01 database and this item is both a component and an output item. Any suggestions are greatly appreciated!!!
Rick Dill: If inventory periods are being used, then you can use the Revaluation journal, go back and revalue inventory as of the date that the cost was changed without revaluing. The hardest part would be to find the date that you want to revalue. I would look at the value entries looking for the first transaction that occurred at the "new" standard cost, and revalue the inventory as of the day before. This will go back and revalue the inventory, and adjust cost entries will correct all entries between then and now (for that one ILE). You would also have to inbound transactions between then and now by revaluing that specific transaction. Inventory periods would force any changes to appear on the first day of the first open period.
Faithie Robertson shared an interesting video on Monte Carlo simulations:
Here's something to bring out the "geek" in you for sure! This is one of the best videos I've seen on Monte Carlo simulations with Excel. It's only 8 minutes long...shorter without his book promotion. (Check out the name of his sheet! LOL!) If you're having trouble wrapping your head around it, consider that the random numbers could be something like the hours per RDLC report build by no. of data items. Hmmm....! :)
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.