ArcherPoint Dynamics Developer Digest - vol 129

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.

Dynamics NAV Coding Best Practices? Not Really

Hey NAV Developers! If you found these things in code, would you cry? If you are new to developing code, maybe not (and that’s okay for now). But, if you are no longer a NAV developer newbie, you may just cry. Especially if the code is being used by many companies. Tell us, which ones do you think are really important?

1. Using “– Separator –” to separate variables and functions
2. Stating variable names with things like g, l, i, cu, var, etc.
3. Using FIND functions instead of ISEMPTY
4. Alternating between using GET and FINDFIRST on the same table
5. Not doing a SETRANGE for all of the primary key fields before trying to check if a record exists
6. Not using text constants
7. Using text constants and requiring them to be the same across objects instead of using a setup table
8. Using NOT (A = B) instead of A<>B
9. Using double negatives (NOT Disabled)
10. Using integers instead of options as parameters and return values (IF Status() = 8 THEN…)
11. Using = TRUE in a conditional
12. Defining variables as global instead of local
13. Defining a field that is supposed to be the same in two tables with different types
14. Naming variables that contain values that don’t match the name
15. Leaving in unused variables
16. Variable names and function names abbreviated to the point that you can’t understand them
17. Lots of code on pages and duplicated across pages
18. Functions that do more than one thing
19. Using FINDFIRST instead of FINDSET
20. Record variable names that do not match the table name

Share your thoughts in the comments below! 

Can You Undo a Posted Inventory Pick in Dynamics NAV?

Gwen Britt posed this question to the team. Rick Dill replies,

“Hi Gwen,

It has been awhile since I have gone through the sequence of testing Undo Shipments, but my recollection is that once warehousing is turned on, you are not able to “undo.”

When you post an Inventory Pick, the order has been shipped (as you know). In NAV, because warehousing complicates the whole “Undo Shipment” process (like what bin should I put it in once I undo it) NAV pretty much considers “Undo Shipment” an illogical process.

So unless something has changed recently, the answer is no. Sorry for lots of words to just say no!”

Gwen quips, “Thank you for the response, Rick…albeit, a little long winded…geez ;-)”

NAV 2017: Issue With the New Template Approach on the Item Card

Rick Dill has been playing around with NAV 2017 and shares this:

The issue occurs when you use a template with a blank Base Unit of Measure field. MS will now default a base unit of measure for you, but there is a problem in that it is not being validated, so the Item Unit of Measure entry is not made, and therefore the Purchase and Sales Unit of Measure is not populated. It saves the value in the Base UOM field so it looks like all is well even if you close and reopen the page.

To make matters worse, because the XREC doesn’t “change,” even typing the defaulted value doesn’t do anything.

The first proposed solution is to make sure your templates have a Base Unit of Measure, because then things work fine.

I also received the note below from MS regarding the status:

Hi Rick,

It is being reconsidered for fixing. My Escalation Engineer made the following recommendation to add at the very least a validation on the Item Unit of Measure, since the development team said they had reason for purposely adding code to auto populate the Base UoM when it is blank. This is not the official fix, just a recommendation/workaround. If you remove the code in grey and add the code in green, the validation takes place when a blank Base Unit of Measure gets auto populated with ‘PCS.. They may also just end up rewriting this entire section of code. You can try the recommendation if you’d like to or wait for the official word from Development.

Table 1301, Function InsertItemFromTemplate

IF Item.”Base Unit of Measure” = ” THEN BEGIN

UnitOfMeasure.SETRANGE(“International Standard Code”,’EA’); // ‘Each’ ~= ‘PCS’

IF NOT UnitOfMeasure.FINDFIRST THEN BEGIN

UnitOfMeasure.SETRANGE(“International Standard Code”);

IF UnitOfMeasure.FINDFIRST THEN;

END;

//Item.”Base Unit of Measure” := UnitOfMeasure.Code; <

Item.VALIDATE(“Base Unit of Measure”, UnitOfMeasure.Code);//<