In the previous chapter, we discussed how Microsoft Dynamics NAV can help us to streamline our production process using both the standard application as well as customized solutions. We talked about five vertical industries and how to fit the application for them.
In this chapter, we will discuss how to use Microsoft Dynamics NAV for these companies using sales and purchase documents and how to integrate this with the built-in Warehouse Management and Reservation processes.
The primary focus of this chapter is on how the application is designed, and where to go to change or enhance the design. Basic knowledge of how to create and process sales and purchase documents in Microsoft Dynamics NAV is a prerequisite.
We will use examples from the same vertical industries—automotive, fashion, medicines, food, and furniture—which we discussed in the previous chapters. After reading this chapter, you will have a good understanding of how to implement Microsoft Dynamics NAV in trading companies.
A trading company purchases and sells items without changing them. The main activities are purchase, storage, packaging, sales, and shipping, as shown in the following screenshot:
Managing the inventory is very important in these companies. Having inventory is crucial for delivering on time and not having to say "no" to customers.
Traditionally, trading companies are divided into wholesale and retail companies. Wholesale companies sell to business and retail companies sell to consumers. Microsoft Dynamics NAV supports both and from the perspective of design (table and posting structure), there is not much difference.
The biggest difference between wholesale and retail for the application is the transaction volume. While the total turnover of a wholesale company can be much higher compared to a retailer, the retailer often has more, smaller transactions. It can be a challenge from an application design perspective to retain a solution that performs well.
Another issue with high volume transaction systems is traceability of the data. Whenever something goes wrong, it is very important to see where this has started and how much data was impacted by the mistake. In low transaction systems, it is easier to find this manually.