All around NAV dev and test
Time is flying while we're cleaning up. Way before Soren started cleaning in Canada and even before Jeremy Vyska joined the team, Mark Brummel gave me his consent that we should be putting some our of cleaning effort on some piece of old code that has been hanging around for too long, totally obsolete, and we surely could make use of his expert hands. So even though you we're not in the known we stopped the dust collection here.
Thumbs up another MVP fellow joining our Clean Team!
And to be fair: we owe Mark some big thumps up any way as he, as you might recall, started to set the pace.
Now you might wonder: what are you guys now going to clean up? And right you are, I haven't mentioned it yet, apart from the title of this post.
Some months ago Mark asked me to join his Master Class Application Design initiative, make it happen in the Netherlands and take part in the Master Class so I could learn and become one of the next trainers on this too. You might have been reading about it already. If not make sure you do and be nice to yourself: subscribe to it. It is really worthwhile as the master class discusses NAV at a meta level bringing more structure to your understanding. And yes, even for those who have been working with NAV for ages already. We're never to old to learn.
The attendants are challenged to rethink on there knowledge in various ways using, for example, the concept of design patters. You're not only challenged by the lecturer itself, but also by applying matters discussed by means of exercises. One of them was to remove the boat anchor from the Post Line codeunit provided to us.
Long story short: next to the one Mark was hinting at, there clearly is another boat anchor collecting dust. Or should I say: collecting rust? And it's not only to be found in an Post Line codeunit, but also in a Check Line codeunit.
Did you ever wonder what the OnRun trigger of the Post Line and Check Line codeunits is used for? I know various students in my Solution Development class did while coloring the code with markers. You know, bluntly said: it is not used at all! We have this code still as a remnant from the past, that hasn't been cleaned away, probably for backwards compatibility. And so we're stuck with these boat anchors.
Taking the Res. Jnl.-Check Line (211) and Res. Jnl.-Post Line (212) as examples we see (more or less) the same code pattern:
These are also to be found in all the other Post Line and Check Line codeunits:
Note that I left out both FA Jnl.-Check Line (5631) and FA Jnl.-Post Line (5632) as these deviate from this pattern.
Wel ....... to be honest I hoped we could just do that: CLEAN IT UP. However, we found two exceptions: the OnRun trigger of both Gen. Jnl.-Post Line (12) and Item Jnl.-Post Line (22) is being called from a number of objects. So let's clean them next time as we will have a close look at why the OnRun trigger is called instead of the the RunWithCheck or RunWithoutCheck function. Feel free to help the Clean Team, or ... Join the Clean Team!
Cleaning is a serious job, you know.
... do you know what other boat anchor is to be found in the Post Line and Check Line codeunits?
Good question Urpo ... no idea either.
Well, you challenged for finding obsolete code, and here I am, trying to do just that :)
I have sometimes wondered what is the function of the function "ReadGLSetup" in Codeunit 12.
It just doesn't make sense to me.
Any idea about this?
Hi Jan, thanx and it perfectly makes sense. So the Item Jnl.-Check Line codeunit should be excluded from this clean up.
I encountered this case a while ago; all kinds of item transactions of various subsidiaries of a company were read into a journal for each subsidiary (over 100) a separate batch.
These batches were then all booked, to enable for a resupply planning of these subsidiaries.
The problem with the 'post-batch' is that the batch is either posted completely, or not. If an error occurred, the stock of the subsidiary was not updated in NAV, and it was not properly replenished.
Because the number of incorrect lines normally was small (but not zero, in almost no subsidiary), it was preferred to be able to handle the bulk of changes and correct the exceptions afterwards.
We then created a process that first would run the "Check Line '- using "IF NOT CODEUNIT.RUN ..." for the "Item Jnl.-Check Line" codeunit: the process had to continue even if there errors occur. The rules in which an error occurs are highlighted and then filtered. Foolowing that all the 'good' lines were posted. The remaining lines could be checked and corrected the next day.
We chose this method because we did not want to rewrite all possible checks that are performed in the "Check-Line"; it would only double code and increase the risk of errors in future adjustments.
"Does this make sense?"
Hi Jan, but for that we have the Post Batch codeunits (which I do not address above) or do you mean it different?
The OnRun can be used to do batch processing and then catch errors without interrupting the posting of the rest of the batch. Until there is a mechanism to do that by calling another function in a codeunit I think this cleanup has to be postponed....
Even cleaners disagree. ;-)
And I knew some would disagree. However, if you have the OnRun called wouldn't that mean you have been too lazy to update your code properly using the RunWithCheck or RunWithoutCheck?
This time I don't agree. I am sure that there is a lit of customized code around that runs the codeunit directly without using the function. I have seen it a lot of times. Removing the code in that trigger would break that customized code.