Dynamics NAV in C# | Part 2 | Classes (Continued)

Disclaimer (Repeated): If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

In my last blogpost I talked about interpreting the table object in NAV as a C# class, how to use C# properties as fields and how to use C# methods as function that then map to another C# class which represents a codeunit.

The example code allowed us to create a Customer using Number Series and Format the Address.

Let’s take this one step further to really explain how this mapping is done, and how to use some of these OOP concepts back in our beloved Dynamics NAV C/AL

Sales Header

Let’s create a new class to create a Sales Header. The goal is to post the document as a Sales Invoice, we will reuse the Customer and FormatAddress classes.

There are a couple of things I’d like to discuss in this example. It might not be the official way to do it in C#, but the idea is to be able to pass a customer class to the sales header and populate the name and the address. I also want the Order Date to be the Posting Date unless the order date is set to a different value. For the latter I probably need to add some more code like Jason shared on part I of this post.

So let’s see what happens if we create a new Sales Header like this:

In the example above we first create the customer like in the first post, then we create a new sales header and “Validate” the Customer. This populates the Name and the Address. Then we set the Posting Date, which sets the Order Date. We write the values to the console to see that it works.

Posting

Let’s repeat using a codeunit as a method and post the Sales Header to a Sales Invoice. To do this, we need the SalesPost  class that we make a method on the SalesHeader class. Like this:

If you would have to fully design this in C#, you would probably use inheritence and try to reuse more elements, but we are trying to map C/AL to C# using the methodology we are used to in C/AL.

So we create a new C# class SalesInvoice which is a subset of the Sales Header, like table 36 and 112 in Dynamics NAV. In the SalesPost class we convert a SalesHeader into a SalesInvoice.

I’ve explored if something like TRANSFERFIELDS exist in C# and found a class on GitHub but decided not to use it for simplicity reasons.

If we use this in our example it would look something like the following:

So we “Post” the Sales Header to a Sales Invoice and print the Customer Name to prove it works.

Let’s take it one step further…

To complete the class lesson, let’s reuse the FormatAddress on the Sales Invoice, like we would do in Dynamics NAV. In the first part of this post you’ve already seen that I had a function in my FormatAddress class that takes the Sales Invoice as a parameter.

Let’s use this, and again, we would make FormatAddress a method on the Sales Invoice class.

You probably get the point now so let’s see what this does:

So to briefly recap, we create a customer class and populate the address. We “Validate” that into the Sales Header and “Post” it into the Sales Invoice. Then we Format the Address.

Conclusion

The idea of this post is to explain C# from a C/AL perspective using names you recognise. A table is a class, A codeunit is a method and A field is a property.

There are probably very smart things you can do in C# to acomplish the same in a more object oriented approach. Personally I like the NAV model since it’s self explaining and simple.

This is what makes NAV rock!

Next episode: Plymorphism in Dynamics NAV. (I hope :).)