The Living Monolith, or Creating Custom Codeunits in Dynamics NAV
The codeunit is a specialized object in Microsoft Dynamics NAV (Navision), intended to hold a set of code functions that do something or that are related to a specific functional area. Sometimes, we need a codeunit that stands on its own, and sometimes, we need a sprawling codeunit that covers a lot of different areas. I’ll try to outline when you’d go which way.
First, let’s talk more in depth about what a codeunit is. A codeunit is a set of functions that are grouped together for some purpose. A codeunit always has an OnRun trigger, and it may or may not require you to call it with a specific record variable. It’s a little bit like a static object in C#/C++/Java/your object-oriented language of choice, in that it feels like a whole bunch of bits of code put together, possibly with some global variables.
I don’t often write custom codeunits from scratch, but it is necessary from time to time. I find that I write two different types of custom codeunits: one type consists of a set of procedures related to a specific functional area, and the other type consists of a set of functions that work together as a routine.
When I’m writing a codeunit that’s a bunch of procedures related to a specific functional area, it’s because I want the functions grouped together for clarity’s sake. If I have some custom functions and processing that need to take place that relate to something, it’s generally a good idea to put them into their own codeunit. When a customer asks for some customizations that should be globally accessible, we’ll often put the customizations in their own codeunit (possibly several codeunits split by functional area, depending on how extensive the changes are). If you look around in NAV, you can see an example of this in the Dimension Management codeunit, where you’ve got a lot of different functions related to dimension handling that can be used all over the system, including within customizations.
When I’m writing a codeunit that’s a bunch of functions working together as a routine, it’s because I want the steps grouped together in a way that’s easily understood and encapsulated. When a customer asks for customizations that relate to custom documents, I’ll often write my own posting routine codeunit for the special document along with the custom document tables. I’ll also write codeunits like this for specialized, complicated procedures. For example, I have a customer who sometimes needs to reverse the sales taxes on posted sales invoices, so I wrote a custom codeunit for them to handle creating the tax reversal credit memo, posting it, and applying it to the original invoice if possible.
The other nice thing about codeunits is that you can put a call to the OnRun trigger of a codeunit in an IF statement, like “IF [Codeunit].RUN([record variable]) THEN . . . ELSE . . . “ This lets you call a codeunit with error handling and then smoothly handle the error instead of grinding things to a screeching halt. You can actually see this in action in base NAV by looking at how the Post Batch functionality works for sales and purchase documents. The Post Batch codeunits call Sales-Post and Purch.-Post for individual sales/purchase documents using that model, so that if the user tries to post 100 orders and one of the ones in the middle doesn’t post, the rest of them are still handled correctly.
If you have any further questions about this or other development questions, please contact one of our development experts at ArcherPoint. If you liked this, you might like to read more of Tom Hunt’s blogs, or check out our collection of Development Blogs.
BONUS VIDEO GAME UPDATE: I picked up Hatoful Boyfriend on Steam, and I just want to mention that it’s the best video game about a high school girl who dates pigeons that I’ve ever played. Everybirdie should give it a try.