Microsoft Dynamics NAV is used in many different vertical industries that often require specific features. Rather than trying to implement all these features in the standard product, Microsoft Dynamics NAV supports the framework and allows developers to design and create the vertical features.
For these features, the 80/20 rule applies. Microsoft delivers 80 percent of the framework which costs 20 percent of our time to implement. The missing 20 percent of the functionality is developed costing 80 percent of the budgeted time.
In this section, we will discuss how Microsoft Dynamics NAV is used for trade in five different vertical industries. For each industry, we will discuss two specific vertical features and how they could be solved.
The fashion industry has trade periods within the seasons. During spring, shops need to order the collection for the next winter and during autumn they buy summer clothes.
The sales orders for each collection are created as normal sales orders but with a shipment date in the future, sometimes six months or more ahead. When using variants, there should be a separate sales line for each variant, meaning, size, and color.
This can be quite a hassle to enter for sales people, so we could speed this up using a template sales line for the main item and hide the individual sizes.
Using a matrix where the x axis represents the size and y axis the color, sales people can quickly enter the quantities. When the matrix is closed, we can update the hidden sales lines. These hidden sales lines are used to calculate the production orders as discussed in Chapter 5, Production.
When the production orders return from the factory, the warehouse and sales people need to decide which customer gets the items first. This can be done using the shipment date but that might not be completely fair if one customer orders in time, meaning six months ahead, and another customer orders too late with an earlier or the same shipment date.
This is where we can start using reservations. The reservations already support variants but the auto reserve functionality of Microsoft Dynamics NAV might not just do what we like.
Changing this functionality is a complex task. The C/AL code for AutoReserve can be found in codeunit Reservation Management (99000845) but should only be changed by experienced developers.
Fortunately, reservations are layered on top of the normal inventory, production, purchase, and sales process. If we change the algorithm, we can remove the current reservations and retest the code to see if the newly created reservation entries are good. This testing process should be done very carefully, on a dataset that is small enough to analyze using Microsoft Excel.
Microsoft Dynamics NAV is used by many car dealer companies and garages because there are some strong add-on products available for this vertical industry.
On top of the normal trade process supported by Microsoft Dynamics NAV, these companies have additional business requirements. Let's discuss two of them.
Each vehicle that is sold needs to be configured and ordered. The configuration should be stored in the database for future maintenance and warranty.
We can compare this to serial numbers or the lot number information table in the standard product. We could create a new master data table called Vehicle and create a record in this table for each car we configure or sell. The number we create for the Vehicle can be used as a serial number in the Item Ledger Entry.
For maintenance, we could have a vehicle journal that creates vehicle ledger entries each time the car comes back for servicing. This helps us keep track of the history and should include information such as mileage. The technical design of this solution can be compared to the squash application we created in Chapter 2, A Sample Application.
In the automotive industry, using the right part is crucial. Different parts can be used on different types of cars and are often even brand independent.
Many vendors offer their assortment in digital formats allowing us to create interfaces with them. Parts should be defined as items, using standard features such as substitutions. As many parts can be expensive and have a low turnover speed, keeping them in the inventory can be very expensive, thus a minimum inventory should be maintained.
Parts can be connected to vehicle types. For example, a car interior mirror could be used for five types of cars. When a service engineer wants to replace such a mirror, he/she can use a filtered item list of all available parts.
In a pharmacy or at another medicine supplier, it is normal that not just every customer is allowed to purchase any item. They cannot sell medicines against cardiac arrhythmia to a healthy person.
Even when someone is allowed to use a certain medication, it is often limited to certain doses. People are often insured for the cost of these medicines but most insurance companies require a contribution.
Microsoft Dynamics NAV does not support item regulation. To support this, we should create new functionality that links items to customers but also allows us to enter the doses and frequency.
From this template, we could periodically create sales orders and shipments. Whenever we ship the medicines, we need to update the template.
When customers need to pay a part of the medication as an own contribution, we require the system to create two sales invoices for one sales order.
This is possible using the standard pre-payment functionality in Microsoft Dynamics NAV. We could send a pre-payment invoice to the customer and handle the other invoices to the insurance companies using combined invoicing. The pre-payments will be automatically deducted from the invoice amount but the value entries on the items will remain intact.
However, the standard system does not allow us to create a pre-payment invoice to another Bill-to Customer No. This would have to be designed and developed.
Where fashion companies have two or three large ordering moments per year where customers carefully consider what to order, most food companies have a daily ordering process of high volume items.
This ordering process is often done by phone or fax where the retailer calls and tells the call center employees what to ship the next day.
Most food companies use an assortment of products. This assortment can change from season to season or contain special action items but is usually stable since that is what most consumers want; meatballs on Monday, pork chops on Tuesday, and so on.
To save valuable time creating a new sales order with the same items each day, we could have the system do this at night.
This could be done using Standard Customer Sales Codes. This standard function in Microsoft Dynamics NAV allows us to create template sales orders with multiple items or other master data supported by the sales process. It also supports fixed quantities that can be adjusted when the sales orders are created.
The sales order can be created from the Customer Sales Codes using the Get. Std. Cust Sales Codes function, as shown in the following screenshot:
Sales order creation
This function could be scheduled in the Job Scheduler to create new sales order each night for the next day. We will discuss the job scheduler in Chapter 9, Interfacing.
When the retailer contacts the call center to complete the sales order, the order entry person should be able to quickly find the correct sales line. If the assortment contains 150 items, this can be quite challenging.
This can be solved by implementing a fast order entry functionality that enables users to key in an item number and quantity on the sales header. The values will be updated in the correct sales line and blanked for the next entry.
With this functionality, the end user can always work from the same place without searching for the correct sales line.
The furniture trading companies have similar issues with variants like fashion companies, with some key differences.
Items like office chairs and desks have far more options compared to clothes and when sold, most consumers buy few with the same specifications rather than a collection of different sizes.
The price of furniture is dependent of the configuration, which fabric we want for the seat, the type of armrest, or even the type of wheel. This configuration also determines the item number.
An office chair or desk can have as much as 1200 possible combinations. We do not want to register all these combinations as items or even as variants.
Most furniture suppliers offer online systems or small external software packages to determine the combination. Once the combination is identified, we can create a new variant code or see if the variant already exists and create the sales order.
Furniture retailers often have many collections they can sell with thousands of items. Most of the items in these collections will never be sold, or get sold as one-off items that are only sold once to one customer.
In this case, it does not make sense to create an item with an item cost and inventory value, but we still want to have some traceability of the item. This calls for two solutions:
- We could create a collection item, which we can reuse each time we sell an item that is similar to another item but not exactly the same, for example, a lamp with a different foot color. On the sales line, we create the possibility for sales people to enter the vendor/collection and an item category. The system should then search for the template item.
- Another solution is to create a new item runtime from the sales order. The sales person will also select the vendor/collection and item category and the system should show a list with items already in the database. If the item is not created, the system should create the item using a template for the posting groups. The sales person can immediately use it and we then have traceability of the items we sold.