Let's create a structure of our own in Microsoft Dynamics NAV. To do this, we must think of something that is not already available in the standard package but can be built on top of it.
For our example application, we will run a squash court. Running a squash court is simple to understand but something we cannot do without changing and expanding the product. In order to define our changes, we first need to make a fit-gap analysis.
After this chapter, you will have better understanding on how to reuse the framework of the Microsoft Dynamics NAV application. We will show how to reverse engineer the application and to study its functionality by going into the application code.
For this example, some new and changed objects are required. The Appendix, Installation Guide, describes where to find the objects and how to install and activate them.
In the first part, we will look at how to reverse engineer the standard application to look at and learn how it works and how to reuse the structures in our own solutions.
In the second part of the chapter, we will learn how to use the journals and entries in a custom application.
Lastly, we will look at how to integrate our solution with the standard application; in our case, sales invoicing.
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.
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 rates for members and non-members.
Although this could be implemented using items as squash courts and customers as players, this would be a typical example of using standard features wrongly. Instead of doing this, we will look at how items and customers are designed and use this to create a new squash court application.
Designing a specific application using standard NAV features is a matter of total cost of ownership (TCO). If only one customer would use this solution, it would be better to use the standard application in a creative way. However, if we deploy the design from this chapter on a multi-tenant architecture and let thousands of companies run it, it would be economically possible to make the best application for the job. Keep this in mind each time you make a decision to design.
To determine the design for this application, we will first look at the parts of the standard application, which we can use to learn how they work. We will use this knowledge in our own design.
In Microsoft Dynamics NAV, customer and vendor master data are maintained using relationship management (RM). For our solution, we will create a new master data for squash players being the business part of the application. This will also be integrated with RM.
To design the squash court, we will look at the design of items in the standard package. The squash court will be the product part of our application with a journal to create reservation entries, which we can invoice.
For this invoicing process, we will use and integrate with the sales part of Microsoft Dynamics NAV.
After we have decided on the design of our application, we can draw the tables and post the routines as we did in the previous chapter. This will clarify the design for others and guide us through the development process.
In the preceding diagram, the objects in Relationship Management and Sales are standard objects that we will possibly need to modify. The objects for the Squash Application are new objects but based on similar objects in the standard application.
In order to keep track of our project, we'll cut the changes into smaller tasks. The first task will be to do the changes in relationship management to be able to create a squash player from a contact. The second part is to create squash courts. The reservation and invoice processes are part three and four.
To create the squash court application, we can use proven design patterns. This will limit the risk of our development's success and make it easy to communicate with others who are familiar with the patterns.
Examples of the patterns we will use are master data, number series, and journals.
Not everything that you need will be documented in patterns. Sometimes it is necessary to innovate. If you do this, it is important to still imagine your design as a pattern and document it for future use.