Microsoft Dynamics NAV 2013 Application Design: Customize and extend your vertical applications with Microsoft Dynamics NAV 2013 , Second Edition

When we do a fit-gap analysis, we look at the company's processes and define what we can and cannot do with the standard package. When a business process can be handled with the standard software we call this a Fit. When this cannot be done it's called a Gap. All gaps have to be either developed or we need to purchase an add-on.

However, even when something could be done with standard software features it does not necessarily mean that doing this is wise. The standard application should be used for what it is designed for. Using standard features for something else might work in the current version but if it changes in a new version it might no longer fit. For this reason it is better to design something new instead of wrongly using standard features.

Designing a squash court application

The basic process of a squash court company is renting the courts to squash players; both members and non-members. There is a reservation and invoicing process handling...

In the first part of the design process, we will look at how to reverse engineer the standard application in order to learn and reuse the knowledge in our own solution.

Creating squash players

For the administration of our squash players, we use the data from the contact table. In the standard product, it is possible to create a customer or vendor with the contact data. We require the same functionality to create squash players so let's have a look at how this is done by Microsoft.

Open Contact Card and try to find this function, as shown in the following screenshot:

We want a function like this for our squash players. So let's get in and see what it does. For this, we need to design the page and look at the actions. The page number in this case is 5050, which we can find by clicking on About this Page in the top-right corner of the page, as shown in the following screenshot:

This option can be very useful to find information about the...

Now, it is time to start on the product part of the squash application. In this part, we will no longer reverse engineer in detail. We will learn how to search in the standard functionality and reuse parts in our own software.

For this part, we will look at resources in Microsoft Dynamics NAV. Resources are similar to using as products as items but far less complex making it easier to look and learn.

Squash court master data

Our company has 12 courts that we want to register in Microsoft Dynamics NAV. This master data is comparable to resources so we'll go ahead and copy this functionality. Resources are not attached to the contact table like the vendor/squash player tables. We need the number series again so we'll add a new number series to our Squash Setup table.

The Squash Court table should look like this after creation:

Chapter objects

With this chapter some objects are required. A description of how to import these objects can...

Our journal is now ready to be posted. We've implemented all business logic, except the posting code.

The posting process of a journal in Microsoft Dynamics NAV has several codeunits for the structure:

• Jnl.-Check Line: This codeunit checks if the journal line is valid for posting.
• Jnl.-Post Line: This codeunit does the actual creation of the ledger entry and register tables and calls other Jnl.-Post Line codeunits if necessary to provide the transaction structure in Chapter 1, Introduction to Microsoft Dynamics NAV.
• Jnl.-Post Batch: This codeunit loops though all journal lines in a journal batch and posts all the lines.
• Jnl.-Post: This is the codeunit that is called from the page. It calls the Jnl.-Post Batch codeunit and takes care of some user messaging.
• Jnl.-Post+Print: This is the codeunit that is called when you click on Post + Print. It does the same as the Jnl.-Post codeunit but with the additional printing of a report...

The last issue on our to-do list is the invoicing process. For this, we use a part of the standard application.

As explained in Chapter 1, Introduction to Microsoft Dynamics NAV, invoicing is done using a document structure with a header and a line table. This has a posting routine that will start the journal transactions.

For our application, we need to create the invoice document and make sure that when posted, it updates our sub administration.

Invoice document

The sales invoice documents in Microsoft Dynamics NAV are stored in the Sales Header (36) and Sales Line (37) tables. We will create a report that will combine the outstanding reservation entries into invoices allowing the user to filter on a specific entry or any other field value in the squash ledger entry table.

Reports in Microsoft Dynamics NAV are not just for printing documents; we can also use its dataset capabilities to start batch jobs.

To enable this, our batch job needs to have a special...

We have now covered everything that is necessary for our squash court application to run but there is one special function of Microsoft Dynamics NAV that needs changing when we add new documents and ledger entries: the Navigate function.

The functionality was already discussed in Chapter 1, Introduction to Microsoft Dynamics NAV. The object is a single page (344) in the application that requires two changes.

FindRecords

The first function we change is FindRecords. This browses through the database finding all possible combinations of document no. and posting date.

FindRecords()

...

// Squash Ledger Entries

IF SquashLedgEntry.READPERMISSION THEN BEGIN

SquashLedgEntry.RESET;

SquashLedgEntry.SETCURRENTKEY("Document No.",

"Posting Date");

SquashLedgEntry.SETFILTER("Document No.",DocNoFilter);

SquashLedgEntry.SETFILTER("Posting Date",PostingDateFilter);

InsertIntoDocEntry(

DATABASE...

In this chapter, we created our own vertical add-on application for Microsoft Dynamics NAV. We used similar data model and posting structures and reused parts of the standard application where appropriate but never wrongly used standard features.

We saw how to reverse engineer Microsoft Dynamics NAV code in order to find out what similar standard functionality to copy, paste, and change for our application.

We also found out how a journal and document posting code unit works and how to structure using Test near, Test far, Do it, and Clean up.

In the next chapter, we will explore the financial functionality of Microsoft Dynamics NAV and even make some changes to this part of the application.