In Microsoft Dynamics NAV, Documents have a limited life cycle and once obsolete, they need to be removed from the table. The Document History pattern helps us to create this. Examples of historical documents are Sales Order Archive, Sales Shipments, Invoices and Credit Memos. Issues Reminders, and Service Invoices. They act as data containers, and are often used to print documents. Once the documents are printed, they can be deleted.
Note
An explanation of how to read and understand posting routines in Microsoft Dynamics NAV is available at https://www.youtube.com/watch?v=Wetd1Fa0rmw&list=PLhZ3P-LY7CqmVszuvtJLujFyHpsVN0U_w&index=4.
When creating History for a Document, we move the data from one set of Document tables to another. This is done using a number of Codeunit objects.
From a functional perspective, this process has many names, such as Posting, Archiving, Issuing, and Registering. This term is used in the User Interface, and should functionally apply to the task.
The Document tables, where we move the data to, have no business logic and exist only for historical reasons. In the standard Microsoft Dynamics NAV Application, they can be removed after printing.
The Codeunit object used for the process has a logical flow called Test Near, Test Far, Do It, and Clean up.
Before the process starts, we need to make sure that everything is in place. It does not make sense to create records in the database, and then later roll back the transaction when a mandatory field is not populated. We should test the data that is closest first, which are the fields in the Document Header and Document Line table.
If the data in these tables is good, we can read singleton and rules tables to see if the external setup values are okay to proceed.
When the traffic lights are green, we can move the data to the next set of tables, and process other nested transactions.
The nested transactions can be creating entries via Journals or other Documents.
At the end of our process, we can clean up the data. This may involve deleting the original records from the database.
The following diagram illustrates how a table can call a function to create a history document. The CreateHistory function can be called Post, the Codeunit can be called Sales-Post, such as Codeunit 80.
When we move Documents from one set of tables to another, we use the C/AL built-in command called TRANSFERFIELDS. This automatically copies all the field values from one table to another, based on the field numbers.
The MSDN article, at https://msdn.microsoft.com/en-us/library/dd301438.aspx, explains the use of the TRANSFERFIELDS command.
This makes field numbering very important. If a field has a different functional meaning, we get garbage; and if fields with the same number have different datatypes, we might get runtime errors. The following screenshot illustrates the error:
If it is not possible to use the same field numbers, the history tables need to be populated field-by-field.
If fields do not exist in the tables, we move data to, the data is not written to the history tables and is therefore lost.