(Further on Microsoft Dynamics NAV:here.)

Designing a journal

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 in the Appendix.

After the import process is completed make sure that your current database is the default database for the role tailored client and run Page 123456701, Squash Setup.

From this page select the Action Initialise Squash Application. This will execute the C/AL code in the InitSquashApp function of this page, which will prepare demo data for us to play with. The objects are prepared and tested in a Microsoft Dynamics NAV 2009 SP1 W1 database.

Reservations

When running a squash court we want to be able to keep track of reservations.Looking at standard Dynamics NAV functionality it might be a good idea to create Squash player Journal. The Journal can create entries for reservations that can be invoiced.

A journal needs the object structure. The journal is prepared in the objects delivered with this article. Creating a new journal from scratch is a lot of work and can easily lead to making mistakes. It is easier and safer to copy an existing Journal structure from the standard application that is similar to the journal we need for our design.

In our example we have copied the Resource Journals.

You can export these objects to text format, and then rename and renumber the objects to be reused easily. The squash journal objects are renumbered and renamed from the resource journal.

all journals have the same structure. The template, batch and register tables are almost always the same, whereas the journal line and ledger entry table contain function specific fields. Let’s have a look at all of them one by one.

Journal Template

The Journal Template has several fields as shown in the following screenshot:

Lets discuss these fields in more detail:

• Name: This is the unique name. It is possible to define as many Templates as required but usually one Template per Form ID and one for Recurring will do. If you want journals with different source codes you need to have more templates.
• Description: A readable and understandable description of its purpose.
• Test Report ID: All Templates have a test report that allows the user to check for posting errors.
• Form ID: For some journals, more UI objects are required. For example, the General Journals have a special form for bank and cash.
• Posting Report ID: This report is printed when a user selects Post and Print.
• Force Posting Report: Use this option when a posting report is mandatory.
• Source Code: Here you can enter a Trail Code for all the postings done via this Journal.
• Reason Code: This functionality is similar to source sodes.
• Recurring: Whenever you post lines from a recurring journal, new lines are automatically created with a posting date defined in the recurring date formula.
• No. Series: When you use this feature the Document No. in the Journal Line is automatically populated with a new number from this Number Series.
• Posting No. Series: Use this feature for recurring journals.

Journal Batch

Journal Batch has various fields as shown in the following screenshot:

Lets discuss these fields in more detail:

• Journal Template Name: The name of the Journal Template this batch refers to
• Name : Each batch should have a unique code
• Description: A readable and explaining description for this batch
• Reason Code: When populated, this Reason Code will overrule the Reason Code from the Journal Template
• No. Series: When populated this No. Series will overrule the No. Series from the Journal Template
• Posting No. Series: When populated this Posting No. Series will overrule the Posting No. Series from the Journal Template

Register

The Register table has various fields as shown in the following screenshot:

Lets discuss these fields in more detail:

• No.: This field is automatically and incrementally populated for each transaction with this journal. There are no gaps between the numbers.
• From Entry No.: A reference to the first Ledger Entry created is with this transaction.
• To Entry No.: A reference to the last Ledger Entry is created with this transaction.
• Creation Date: Always populated with the real date when the transaction was posted.
• User ID: The ID of the end user who has posted the transaction.

The Journal

The journal line has a number of mandatory fields that are required for all journals and some fields that are required for its designed functionality.

In our case the journal should create a reservation which then can be invoiced. This requires some information to be populated in the lines.

Reservation

The reservation process is a logistical process that requires us to know the number of the Squash Court, the date and the time of the reservation. We also need to know how long the players want to play. To check the reservation it might also be useful to store the number of the Squash Player.

Invoicing

For the invoicing part we need to know the price we need to invoice. It might also be useful to store the cost to see our profit. For the system to figure out the proper G/L Account for the turnover we also need to define a General Product Posting Group.

• Journal Template Name: This is a reference to the current journal template.
• Line No. : Each journal has a virtually unlimited number of lines; this number is automatically incremented by 10000 allowing lines to be created in between.
• Entry Type: Reservation or invoice.
• Document No.: This number can be used to give to the squash player as a reservation number. When the entry type is invoice, it is the invoice number.
• Posting Date: Posting date is usually the reservation date but when the entry type is invoice it might be the date of the invoice which might differ from the posting date in the general ledger.
• Squash Player No.: A reference to the squash player who has made the reservation.
• Squash Court No.: A reference to the squash court.
• Description: This is automatically updated with the number of the squash court, reservation date and times, but can be changed by the user.
• Reservation Date: The actual date of the reservation.
• From Time: The starting time of the reservation. We allow only whole or half hours.
• To Time: The ending time of the reservation. We only allow whole and half hours. This is automatically populated when people enter a quantity.
• Quantity: The number of hours playing time. We only allow units of 0.5 to be entered here. This is automatically calculated when the times are populated.
• Unit Cost: The cost to run a Squash Court for one hour.
• Total Cost: The cost for this reservation.
• Unit Price: The invoice price for this reservation per hour. This depends on whether or not the squash player is a member or not.
• Total Price: The total invoice price for this reservation.
• Shortcut Dimension Code 1 & 2: A reference to the dimensions used for this transaction.
• Applies-to Entry No.: When a reservation is invoiced, this is the reference to the squash entry no. of the reservation.
• Source Code: Inherited from the journal batch or template and used when posting the transaction.
• Chargeable: When this option is used, there will not be an invoice for the reservation.
• Journal Batch Name: A reference to the journal batch that is used for this transaction.
• Reason Code: Inherited from the journal batch or template, and used when posting the transaction.
• Recurring Method: When the journal is a recurring journal you can use this field to determine whether the amount field is blanked after posting the lines.
• Recurring Frequency: This field determines the new posting date after the recurring lines are posted.
• Gen. Bus. Posting Group: The combination of general business and product posting group determines the G/L cccount for turnover when we invoice the reservation. The Gen. Bus. Posting Group is inherited from the bill-to customer.
• Gen. Prod. Posting Group: This will be inherited from the squash player.
• External Document No.: When a squash player wants us to note a reference number we can store it here.
• Posting No. Series: When the journal template has a posting no. series it is populated here to be used when posting.
• Bill-to Customer No.: This determines who is paying for the reservation. We will inherit this from the squash player.

So now we have a place to enter reservations but we have something to do before we can start doing this.

Some fields were determined to be inherited and calculated:

• The time field needs calculation to avoid people entering wrong values
• The Unit Price should be calculated
• The Unit Cost, Posting groups and Bill-to Customer No. need to be inherited
• As final cherry on top, we will look at implementing dimensions