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 it cannot be done it's a Gap, we can fill a gap by developing a solution or purchasing an add-on.

But 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 was 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 the 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 different...

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 our squash players administration we will 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 the 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 upright corner of the page as shown in the following screenshot:

This option can be useful for finding information about the fields...

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 use 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 umbrella data 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 be found...

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.
• Jnl.-Post Batch: This codeunit loops through all journal lines in a journal batch and posts all the lines. There is a dialog.
• Jnl.-Post: This is the codeunit that is called from the page. It calls the codeunit jnl.-post batch and takes care of some user messaging.
• Jnl.-Post+Print: This is the codeunit that is called when you push post + print. It does the same as the jnl.-post codeunit but with the additional printing of a report defined in the journal template...

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, 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 property, ProcessingOnly (as shown in...

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. The object is a single page (344) in the application that requires two changes.

FindRecords

The first function we change is FindRecords. This browses though 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::"Squash Ledger Entry",0,
    SquashLedgEntry.TABLECAPTION...

In this chapter we created our own vertical add-on application for Microsoft Dynamics NAV. We have 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 learned how a journal and document posting codeunit 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.