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.
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.
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
Human resources setup
Production schedule setup
Nonstock item setup
Service Mgt. setup
Source code setup
Change log setup
SMTP mail setup
Job queue setup
Online map setup
Interaction template setup
Employee portal 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:
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.
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.
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.
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.