ArcherPoint Dynamics NAV Developer Digest - vol 210
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.
Problem Copying a Company with Image Tracker
Len wants to know, “I am not sure if anyone has run into this, but I encountered a problem copying a company. I received the error message shown below, a SQL error for an invalid object name. I found that if you open SQL Management Studio and find the $ndo$navappschematracking table and remove the reference to Image Tracking, that the problem is solved. I do NOT know if there are any other implications but if anyone is having the same problem, this would be a place to start. Have a great day!”
Figure 1 - SQL Error for Invalid Object Range
Matt T is curious, “What would happen if you uninstalled the Image Analyzer extension? I don't know if it is related.”
Len notes, “I actually uninstalled all V2 extensions. It looks like there is an ’MS- Image Analyzer’ (in the tables) and an ’Image Analyzer’ as well. I wonder if the one with ’MS’ in front is an old one...”
Bill W adds, “Synchronization schema for all tables? It sounds like the table was dropped on the SQL side of things but the application still had the definition.”
Costing Issues with Drop Shipped Items
Crystal Hill has a problem. “Hi All! I'm working with one of our customers who has Items that are exclusively Drop Ship. This means the process to update the Unit Cost field on the Item Card does not update this field, as all 'Drop Ship' entries are excluded from the process. This field stays at zero or becomes skewed because of a few entries that are not drop shipped. Because the user sometimes does not populate the Unit Cost on the PO and because zero is picked up as the Unit Cost on the SO, this is causing costing problems in their interim accounts. My question is, has anyone resolved this problem for another customer? All ideas welcome.”
Kyle responds, “This is such a complicated topic. Are the items that are being drop-shipped actually in inventory? If so, what is the costing method?”
Gwen Britt adds, “I can't help but think that the numbers are not skewed. The Unit Cost is accurately reflecting what is happening. It seems to me that the user not populating the cost on the PO is the issue.”
The Future Will Always Exist: Quantum Mechanics
Jon states, “The future will always exist. Here’s a glimpse into quantum computers.”
Michael H adds, “To understand more about quantum mechanics, read In Search of Schrödinger's Cat: Quantum Physics and Reality by John Gribbin.”
Your Team Should Work Like an Open Source Project
Bill Warnke shares this post from 2012, where Ryan Tomayko highlights his idea of borrowing natural constraints of open source software development when designing internal process and communications, noting “It is older (2012), but the only thing I don't agree with is the email. Email should essentially be eliminated from the process, or at most be used as a notification mechanism.”
Matt T agrees, “I too agree with most of this. One of the things I've been struggling with whenever I see a process that I think would benefit us is scaling. Oddly enough it's not whether or not it will scale up, it's whether it will scale down. We're a team of 30 developers, but the vast majority of the time there is only one developer on a project at a time. A team of 30 supporting 300 products.”
Bill adds, “I tend to think there's a minimum no matter how many developers or people are on a project. I also think of time frame. It might be one person over a short period of time, but it could be all 30 developers over 5-10 years. Talk about asynchronous!”
If you are interested in NAV development, be sure to see our collection of NAV Development Blogs.