Microsoft Dynamics NAV has some basic design patterns that are reused throughout the application and are necessary to understand the concepts of this book.
Databases need unique records. The application has two ways of making this happen.
Some tables have automatic incremental numbering that cannot be influenced. These are often accounting tables that have auditable purposes. Examples of these tables are G/L entries, G/L registers, and VAT entries.
The other way is using a flexible alphanumeric code. In some setup tables, users are free to create their own numbers like in the location table but most of the time, number series functionality is used. These can be influenced by the end user depending on their access rights. Let's have a closer look at them:
Users can define their own numbering, usually starting with an alphanumeric character. Numbering can be done automatically, manually, or a combination of the two. Numbers can have a starting date and incremental number. This way you can number your Sales Invoices SI11-0001. SI means Sales Invoice, 11 means 2011, and 0001 is the incremental number.
For example, number series can be linked to each other making it possible to have a different number series for national and international customers.
Most master data tables in Microsoft Dynamics NAV have two description fields, but it is possible to add extra text.
The text can be defined for all languages in the system and made valid for a specific period.
We can enable or disable using the text for most documents available in the system, so we can have some long text for the Sales Quote and some shorter text for the Sales Invoice, as shown in the following screenshot:
The main reason Microsoft Dynamics NAV consultants like you to use numbers like SI11-0001 is because of the Navigate functionality. This functionality makes it possible to find all information in the database linked to this document. If you name your Sales Invoice 110001 and your Purchase Invoice the same, the system would not be able to find the information at a detailed level.
When navigating to Posted Sales Invoice 103006 in the CRONUS Demo database, we get all the information that is linked to this number.
Navigation shows both documents and entries. Using the Show option, we can drill down into the records and go even deeper into the information. Navigation is present at most pages that show posted transactions and historical data.
An ERP application can be used in many different ways and to make it work in the way we want, we need to set it up correctly. We already discussed that Dynamics NAV has far less setup than other ERP packages and is more likely to be changed, but nonetheless there is setup work to do.
Every part of the application has its own setup table. There are also some application-wide or cross-application setup tables. During the implementation, we need to make sure to touch all of these tables. Changing these setups after the implementation should be done with great care.
The setup tables use the singleton table design pattern. The following table shows all Microsoft Dynamics NAV setup tables grouped by type:
|
Specific setup tables |
Application-wide setup tables |
|
General ledger setup Sales & receivables setup Purchases & payables setup Inventory setup Resources setup Jobs setup Marketing setup Human resources setup Production schedule setup FA setup Nonstock item setup Warehouse setup Service Mgt. setup Manufacturing setup |
Source code setup Change log setup SMTP mail setup Approval setup Job queue setup Online map setup Interaction template setup Employee portal setup Notification setup Order promising setup BizTalk management setup |
When we open a setup from the application, we see some options, including the numbering we discussed earlier:
Microsoft Dynamics NAV is very flexible in its posting to the General Ledger. This is set up in posting groups. These form a matrix that is filtered out by the application.
Most application areas have one or more posting group tables:
- Customer posting group
- Vendor posting group
- Inventory posting group
- Job posting group
- Gen. business posting group
- Gen. product posting group
- Bank account posting group
- VAT business posting group
- VAT product posting group
- FA posting group
|
|
|
We'll discuss posting groups in more detail in Chapter 3, Financial Management. |
|
When it comes to pricing and discounts, Microsoft Dynamics NAV has a very simple yet effective way of calculating.
All sales and purchase prices are stored in four simple tables:
- 7002 – Sales Price
- 7004 – Sales Line Discount
- 7012 – Purchase Price
- 7014 – Purchase Line Discount
The system finds the appropriate price by filtering down in these tables. The narrower the filter, the more likely the price is applied.
For example, the normal price of item 1972-W on the item card is 97,480, but from 1-1-2011 it is 843,345.
The filtering is done in codeunits Sales Price Calc. Mgt. (7000) and Purch. Price Calc. Mgt. (7010). We'll discuss this structure in Chapter 2, A Sample Application, where we will also create such a structure for our own application.
Throughout the application, an unlimited number of dimensions can be used to analyze the data. These dimensions are inherited from master data tables.
The application has two global dimensions that are directly posted into each transaction. Six other dimensions can be defined as shortcut dimensions to be directly used in journals and documents. An unlimited number of additional dimensions can be added but need to be accessed with additional effort.
The preceding screenshot shows how Global and Shortcut Dimensions can be used in a Sales Document.
Microsoft Dynamics NAV has built in OLAP possibilities. It allows us to create cubes to be analyzed within the application or in SQL Server analysis services.
Although the cubes can be updated real time during posting, it is highly recommended to update them periodically in a batch. Also, the number of dimensions has an impact on the performance of the system.
Dimensions were redesigned in Microsoft Dynamics NAV 2013. The redesign has a huge impact on application performance and can reduce database size up to 30 percent.