In the previous chapters, we looked at how companies work with ERP in production and trade businesses. All these companies work together to bring finished products to the stores where end consumers can buy them.
During this process, the products move around between the companies. This is done using different kinds of transportation, such as trucks, ships, trains, and airplanes. It may also be necessary to store the products in a warehouse until they are sold or moved to the shops.
More and more companies make a decision to outsource logistics rather than having their own transportation. When this is the case, logistics can be a separate part of the supply chain. This chapter discusses the process and the effects on the ERP system.
One of the specific aspects of logistics companies is that the products they handle are not their property. Although they are a part of the total cost of the consumer product, they don't care about the detailed value of their inventory. Logistics companies sell warehouse handling, storage, and transportation as services.
Microsoft Dynamics NAV does not have built-in functionality to handle this so, in this chapter, we will discuss how to design an application to do this.
There are several add-on solutions for this business and in a real-world situation those add-ons should be evaluated as potential solutions. In this chapter, we will discuss how to design and create a basic framework for such an add-on application that can be easily extended without adding too much complexity.
After reading this chapter, you will have a better understanding of how to design a solid add-on solution and how to integrate it into the standard Microsoft Dynamics NAV product.
In this chapter, we will demonstrate how an add-on for Microsoft Dynamics NAV should be designed. In this example, we create a solution for a Storage & Logistics company. This is chosen because the functionality is similar to the existing functionality in Microsoft Dynamics NAV (warehousing) and is a good example of building on top of standard application features.
We will start by analyzing the business process and then discuss the reasons why we won't use standard application features and explain the modules our new application will have.
The next step is to go deeper into these modules and define the design patterns for each of them. We will then walk through the application like we did in the previous chapters and reverse engineer it to explain how all the pieces were designed.
To do this, we need to download and install the application. As we progress in the chapter, we will discuss most of the objects that can be opened and analyzed in the Microsoft Dynamics NAV development environment.
With this chapter, some objects and Dynamic-link library (DLL) files are required. The Appendix, Installation Guide, describes how to import and activate them.
After the import process is complete, make sure that your current database is the default database for the Role Tailored Client and run Page 123456701, Storage & Logistics Setup from the Object Designer in the Classic Client.
From this page, select the Initialize Storage & Logistics option, as shown in the following screenshot:
To design a solid solution for a specific market, we first need to analyze the business processes and see where the fits and gaps are with the standard product.
The companies that will be using this solution are logistics providers. These companies do not buy and sell products but sell logistics services such as transportation and storage.
There can be various moments in the supply chain where these companies are required. Products are often manufactured in companies all over the world and shipped to consumers elsewhere. Products can cover great distances, as shown in the following diagram:
Microsoft Dynamics NAV, like many ERP systems, is designed for people to handle their own products and supports the process of costing as we have seen in the previous chapters. For logistics service providers, this inventory control and valuation functionality is not necessary since the products are not their property. This means that they would want to use the warehouse functionality without the item ledger entries, which is very difficult in Microsoft Dynamics NAV.
Logistics service providers also offer transportation solutions. They will pick up the products and deliver them to the customer. The process includes combining different stops in routes resulting in a more cost-efficient way of transportation. This functionality is not available in Microsoft Dynamics NAV.
In this chapter, we will design three new modules on top of Microsoft Dynamics NAV that integrate with each other and could still be used separately. These modules also integrate with the standard application through Sales & Purchase Documents.
The first part of the application is the storage module. This allows us to receive and ship products and move them internally in the warehouse. The design of this module is very similar to the warehouse documents in the standard application that we discussed in Chapter 6, Trade.
The logistics module supports the planning of routes, delivering the products to the consumers. This is integrated into the storage module but can also be used from sales shipment documents in the standard application.
For the design of this module, we have looked at the production orders in Microsoft Dynamics NAV that we discussed in Chapter 5, Production. The routes and shipments have a Status field that indicates the progress, similar to a production order.
The storage and transportation services are then invoiced to the customer periodically or when the products leave the warehouse.
For this, we will use the standard Microsoft Dynamics NAV invoicing solutions but we will add a new Income & Expenses module in between the logistical solution and the invoicing functionality.
We have looked at the design of Job Ledger Entries and how they are invoiced. This will be discussed in the next chapter.