Skip to main content
Submitted by Suzanne Scanlan on 7 June 2019

ArcherPoint Dynamics NAV / Business Central Developer Digest - vol 244ArcherPoint's Developer Digest Weekly Blog

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 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.

Customer Requirement: Same SKU, Different Packing Requirements Per Location

Kyle asks: “Has anyone done a modification where you've added a SKU Unit of Measure table and had the sales order logic use that instead of the item unit of measure?”

Matt Street asks for clarification: “Can you give a use case? The SKU unit of Measure table you mention - how would it be different than the Item Identifier table?”

Kyle continues: “Item X is manufactured the same at two plants, but each plant packs it differently since different customers have different packing requirements. So, the selling/shipping unit of measure will be different. Plant A defines a pack of Item X as 24, but plant B defines a pack of Item X at 30. Our plan was to use one SKU for Plant A and another SKU for Plant B. But if there is only one item, then you only have one place to store Item Units of Measure.”

Matt S asks: “So you need 2 units of measures defined (Pack A and Pack B) and then use The Item Identifier table to define a ‘SKU’/unique barcode for each?”

Kyle confirms: “Correct. I know we will have to do a modification to make sure the correct SKU/UOM gets onto the sales order (Plant A gets Pack A, Plant B gets Pack B), but we need a place to store the units of measure.”

Matt S wants more details: “Are they set up to use barcodes? Still confused as to why you need a new table. If you prefixed the barcode with a location segment, they should be able to keep it straight. They would then create a new Item Identifier for each barcode pointing at the correct NAV item/variant/UOM. You could then create a mod on the SO sales line (or other document dealing with items) to look at the Item Identifier table when they enter the No. field and have that set the line to the appropriate UOM as well as doing some sort of location verification. CSM and LS Retail have a few tricks to  interpret SKUs/barcodes to NAV Item/Variant/UOM. What happens if location A transfers inventory to location B?”

Todd T adds: “Matt, we want to set up one BOX unit of measure for an item. This would be the ‘Sales Unit of Measure’. Two physical locations (defined by Location Code) could have different quantities per box. Somewhere we have to have a different ‘Qty Per’ based on ‘Location Code’. Where would we store this value? For transfers, that is a very fair question. We would have to use the unit of measure from the ‘Transfer-from’ location.”

Matt S: “I would be glad to discuss potential solutions and have some ideas, but other questions as well. Grab some time on my calendar, and I would be glad to brainstorm with you.” 

Synchronize Versus Recreate in Visual Studio Code

Tom H: “I've been working in Business Central, and I have an interesting issue. I hit F5 in VS Code to run my changes, then I get into BC and change some records in the database. I finish my testing and go back to code. The next time I hit F5 and run my changes, all of the records I modified in the database have reverted to where they were when I started, as if I haven't changed any records at all. It's like I've got a database snapshot I'm always reverting to. I'd actually like for the changes I make to stick. Does anyone know how I can make the database changes stick around? I've tried rebuilding the container, restarting the container, and restarting my computer; none of them had an effect.”

Kyle suggests: “This is what works for me: 


Run stuff 

Come back to VSC and hit the Stop button, which disconnects the debugger from the NST (this is probably the source of your rollback) 

Lather, Rinse, Repeat 

You can also try F6, which does not turn on the debugger. It just does a full compile and publish.”

Matt T offers: “Check your launch file. You want to change one of the settings to synchronize instead of recreate.”

Tom H: “This was the answer. Thank you, Matt. I'm trying to take some notes on stuff I observe while writing BC code, and I might turn it into a blog entry at some point.”

If you are interested in NAV development, be sure to see our collection of NAV/BC Development Blogs.

Read the "How To" blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

Blog tags