While writing your own customized code for Dynamics NAV, it is important to choose where to write that code. If you try, you will see that the same code can be written in different places and the application will still work as you had intended. Unfortunately, not all places are equally good. Depending on where we write our code, it will be easier or more difficult to expand or change functionality. That's why we have to choose the best site. In this section we will give you some guidelines for choosing where to write your code.
When a field is filled, a special trigger runs the OnValidate trigger of the field. For a given field, you will find an OnValidate trigger on the page where the user enters the data and also on the table itself. Whenever possible, write your code on the OnValidate trigger of the table.
A field can be shown on multiple pages. If you choose to validate the field on the page, you will have to replicate your code in all the pages where the field is shown. This will make your code difficult to maintain.
Dynamics NAV checks if certain fields are filled or filled with certain data only when the system needs it. As an example, you can create a new customer just by giving it a number, which is the way to identify the customer. Then you can leave the customer card without filling any other field. You are not using the new customer yet, so the system allows you to do it. However, if you try to select the newly created customer on a sales order, you will get the following error:
The system does not need you to fill the Gen. Bus. Posting Group field of a customer until you want to use the customer on a transaction, either a document or a journal line. Some other fields from the customer card are also mandatory in order to select the customer on a new transaction. Dynamics NAV checks the needed data one by one and also gives message errors one by one. If you enter the customer card and fill in the required field, you will get the following error:
You will get an error one after another until all required fields are filled. When you have finally inserted the sales order and tried to post the shipment, many other validations are done. In fact, the posting routines are the ones that do the big job, data checking.
Posting dates, dimensions, item availability, posting groups' setup, and many other questions are checked while posting. This means that it is when posting that most of the data is required.
Batch jobs are written using a Report object. Typically, batch jobs are not to be done for all records on a table, but for a set of them. In most cases, it is the user who selects what set of data has to be processed. Report objects are the ones that best suit those requirements, since they have an interface that allows users to select options or filter data.
The previous screenshot is an example of a Batch Post Sales Invoices report. It is used to post multiple invoices. As we can see in the screenshot, there is an Options tab, and a Sales Invoice tab that allows users to filter data. In the example, we have chosen to only post invoices from customer number 10000 onwards.
In this section we have seen where to write customized code. Besides following the guidelines given in this book, there are other options that will help you choose where to write your code. When you need to write a new functionality, you can search for a similar functionality on the standard application and try to mimic the structure.