Dynamics NAV has one big key word (among others), called post. If you read the word post anywhere in an application or see the following icon, it means that if you click on the button, a routine will be run and this will lead to posted documents and posted entries that are on their last stage. It is the trusted data that won't change anymore. This is important for many IT and accounting audits.
As explained in The data model section of this chapter, Dynamics NAV has some tables called Entries
(G/L Entries
, Cust. Ledger Entries
, Vendor Ledger Entries
, Item Ledger Entries
, and so on) that correspond to transactions related to master data. The only way to insert data into entry tables is through the posting routines. Numerous validations are carried out during posting routines as the system has to check whether all data is correct and that no inconsistencies exist.
One unique posting process usually creates multiple entries, and all of the entries are related and consistent to each other. For instance, when you post a sales invoice, the system needs to create the following entries (depending on what the invoice includes):
As explained in The data model section of this chapter, entries are created by reading information from a journal line. Therefore, if you choose to post a document, the first step that the system must follow is to create all the related journal lines. Then all the related entries have to be created. The following diagram shows the general schema:
Out of the box, posted data cannot be modified or deleted. Posted documents can be deleted, but only after a paper copy has been printed for manual archiving.
Not being able to modify or delete ledger entries data is one of the most basic requirements of any legitimate accounting software.
This may cause some frustration for the Dynamics NAV users who are used to a home-grown system or other off-the-shelf accounting software, where they can just void the data without any repercussions. This is usually not an issue when you only have one person using the system because they know exactly why a transaction needed to be "voided". When your business grows to a certain size, just voiding transactions will not only raise a slew of questions from your auditors, but also lead to inconsistent financial statements for you to run your business.
As mentioned earlier, there are a few exceptions where posted documents can be deleted or fields changed; they are as follows:
You'll notice that none of the preceding exceptions deal with any dollar value or the transaction date. This is strictly implemented to maintain the integrity of your financial data!
As we have seen in the earlier sections of this chapter, when one document is posted, the result consists of several entries that are all consistent to each other and to the rest of the application data.
If data cannot be changed, how can users correct a mistake in the data? The solution is to post reversed documents or entries so that the net effect of the transaction is zero. This will give you a complete paper trail of what happened to a transaction and what actions are done to "void" that transaction.