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):
- Customer Entries: It is used to track all the transactions related to the customer.
- Item Entries: It is used if an invoice contains the items of which you need to reduce the stock of, plus if in the future you need to track all the transactions related to one particular item.
- VAT (Tax) Entries: You will need to report to the tax authorities, all VAT (tax) charged to your customers. Therefore, the VAT (tax) amount charged on every invoice has to be tracked.
- General Ledger Entries: Accounting rules say that when you issue an invoice, you have to record the related amounts on certain accounts. Dynamics NAV does this for you by creating G/L entries.
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:
- Posted documents can be deleted after you have printed a paper copy for your ever hungry file cabinet. This feature cannot be used as a way to undo the document, as only the document is deleted but the corresponding ledger entries remain in the database.
- Some specific fields can be modified by a user manually, such as the Due Date field in customer and vendor entries or Shipment Agent Code in the shipments header. Changes to these fields are handled by special codeunits.
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.