Friday, November 04, 2016

Code changes - NAV 2016 to NAV 2017 - Tips, Tricks & Facts #5

Hi guys, I am gonna talk about the code changes that I liked in NAV 2017 and you must know about them too.

Coding in NAV 2017 is better, as expected.

Just to give an overview. I will cover some examples as follows,

1. Codeunit 80 - OnRun Trigger - This trigger used to be a home of like more than a thousand lines of code. Well now, it has been decreased to a hundred lines of code, give or take. Check the image below,

This screenshot is of CU 80 OnRun trigger The highlighted function in yellow is a new addition and in this function exist other new functions and likewise. I like it. :-)

2. Codeunit 80 (again) - PostItemJnlLine Function - 

In the "new way" which is NAV 2017, instead of assigning all the values in the function itself, there are new functions in respective tables which assign values to posted tables.

There is a lot of other new stuff to check out. Check NAV 2017 and share your knowledge in comments.

(Since my posts cannot be complete without extensions. Therefore,)

Talking about extending code - Well, to be true I am still unsure about how to alter the code and offer flexibility that we used to have in the old NAV to our clients. There still is a lot to understand from extensions point of view. :-?

A question which I still can't answer to myself, How will we (customization wise) manage the re-implementation with clients upgrading to NAV 2017? I mean there is good potential in extensions but it requires lessening the scope a lot for the clients whose databases are heavily customized (by which I mean a lot of customized code in the standard objects).

I hope that with the new development environment coming up soon a lot of possibilities might open up. Like writing code in between a function like PostItemLine (a new function in CU 80 in NAV 2017) OR lots of other new and old functions existing in tables, codeunits etc.

Many of us have customized some major codeunits in NAV till now and some of these customization were very crucial for the client. Let's say the scope of these custom functionalities cannot be narrowed down because of the kind of code written already. Happens in real world! Doesn't it?

With this post, I am answering my questions partially. As we can see a lot of new functions have been added in NAV 2017 which lessens the code existing in other functions (like example no. 1 above). These changes will surely help in extending the code (with extensions).

Please comment your thoughts and tips on how to win over typical situations (like the one I have described above) if the client decides to move forward NAV 2017 with extensions. At the moment I am circling around code to find ways on how to deal with typical situations using extensions.

Keep Learning!