Why Posting Date Errors Occur in Microsoft Dynamics NAV

A user may receive an error such as the following when posting a transaction in Microsoft Dynamics NAV:

Figure 1: Error message when a posting date error occurs in Microsoft Dynamics NAV

There are 2 areas in NAV where a Posting Date range may be defined:

• General Ledger Setup
• User Setup

This error could be due to any of the following circumstances:

1. A user is posting outside of their designated User Setup posting date range
2. A user is posting outside of the designated General Ledger Setup posting date range
3. There is an inconsistency between the User Setup and General Ledger Setup posting date ranges

To resolve this issue, review the following scenarios:

Scenario 1

Go to Departments -> Administration -> Application Setup -> Users -> User Setup and locate the user who has encountered the posting date range error. Next, verify the user’s Allow Posting From and Allow Posting To date range.

Figure 2: User Setup Table displaying Allow Posting From and Allow Posting To range

If the User ID is not set up with a posting date range in the User Setup table, go to Departments -> Financial Management -> Setup -> Administration -> General Ledger Setup to verify the Allow Posting From /Allow Posting To date range on the General tab.

Figure 3: General Ledger Setup Administration Setup screen, entering Allow Posting From and Allow Posting To dates.

In the example above, PO #104005 must have a posting date outside of 7/1/2013 – 7/31/2013. Since the User Setup posting date range is blank, the system is validating against the General Ledger setup. To resolve the error, first determine if the posting date on the document is correct. If the posting date is accurate, an authorized user will need to enter the company’s posting date range. Company business rules will dictate who can post different types of transactions and in what periods.

Scenario 2

Go to Departments -> Administration -> Application Setup -> Users -> User Setup and locate the user who has encountered the posting date range error. Next, verify the user’s Allow Posting From and Allow Posting To date range.

Figure 4: User Setup Table displaying Allow Posting From and Allow Posting To range

If the User ID is set up with a posting date range in the User Setup table, PO #104005 must have a posting date outside of the 6/1/2013 – 6/30/2013 range.

To resolve the error, first determine if the posting date on the document is correct. If the posting date is accurate, an authorized user will need to update the user’s posting date range. Company business rules will dictate who can post different types of transactions and in what period.

Scenario 3

It is important to note that even if a user is posting a transaction within their specified posting date range of the current month, a posting date range error can still occur if the General Ledger Setup -> Allow Posting From date is earlier than the User ID -> Allow Posting From date:

Figure 5: Comparing The Allow Posting From dates between the GL Setup and the User Setup.

This typically occurs when posting production consumption entries or other negative inventory transactions with the date mismatch above. It is strongly recommended that both the General Ledger Setup and User Setup date ranges be set to the current month at all times. Should a user need to post in a prior period, the User Setup -> Allow Posting From date should be backdated as per company business rules for the specified users:

Figure 6: Backdating the User Allow Posting From date to allow posting to a prior period.

In Summary

Upon posting transactions in NAV, the program will always validate against the User Setup table first

If the User Setup table is not populated, the program will next validate against the General Ledger Setup

It is strongly recommended that the General Ledger Setup and User Setup posting date ranges be set to the current month at all times. If specific users need to post in a prior period, their User ID -> Allow Posting From date field should be backdated accordingly. This will prevent posting inconsistencies such as in Scenario 3.