When we post a sales invoice, the system will generate the G/L Entries based on the sales lines. To avoid creating too many entries, they are compacted. This is done using a buffer table, the Invoice Post. Buffer:

Only for the combination of the preceding listed fields, a G/L Entry record is created. As we can see, the description is not one of these. This results in G/L Entries with the posting description of the sales header, which is often confusing for accountants when looking at the G/L Entries.

As an example, we will generate a sales invoice with one G/L Account line selling one of these books.

When we post this invoice, we will get these G/L Entries. Note that the description has gone.

To change this behavior, we have to change the Invoice Post. Buffer table. The description field needs to be part of the unique combination since the grouping is done using a FIND command in the UpdInvPostingBuffer function in Sales-Post Codeunit (80):

UpdInvPostingBuffer()
...
InvPostingBuffer[2] := InvPostingBuffer[1];
IF InvPostingBuffer[2].FIND THEN BEGIN
  InvPostingBuffer[2].Amount := 
    InvPostingBuffer[2].Amount + InvPostingBuffer[1].Amount;
  ...
  InvPostingBuffer[2].MODIFY;
END ELSE
  InvPostingBuffer[1].INSERT;

This requires the following two steps:

When this is done, a change is required in populating the buffer table. This is done in the PrepareSales function in the table Invoice Post. Buffer (49) itself:

PrepareSales()
CLEAR(Rec);
Type := SalesLine.Type;
"System-Created Entry" := TRUE;
...
"Job No." := SalesLine."Job No.";
"VAT %" := SalesLine."VAT %";
"VAT Difference" := SalesLine."VAT Difference";
//* Description >>>
Description := SalesLine.Description;
//* Description <<<
IF Type = Type::"Fixed Asset" THEN BEGIN
  ...
END;

The last change we are going to make is in the posting routine of the sales documents. This is the Sales-Post codeunit (80) we discussed in Chapter 2, A Sample Application:

IF Invoice THEN BEGIN
  // Post sales and VAT to G/L entries from posting buffer
  LineCount := 0;
  IF InvPostingBuffer[1].FIND('+') THEN
    REPEAT
      LineCount := LineCount + 1;
      Window.UPDATE(3,LineCount);

      GenJnlLine.INIT;
      GenJnlLine."Posting Date" := "Posting Date";
      GenJnlLine."Document Date" := "Document Date";
//* Posting Description now from buffer table >>>
//      GenJnlLine.Description := "Posting Description";
      GenJnlLine.Description :=
        InvPostingBuffer[1].Description;
//* Posting Description <<<
      GenJnlLine."Reason Code" := "Reason Code";

Instead of the posting description of the sales header, we will now use the new field in the buffer table. When we post the same invoice again, this is the changed result:

This makes it a lot easier to read the general ledger.

Although the G/L Entry table has a lot of information, some companies want to add extra fields to it and populate these in the posting process.

For this example, we will use the database with the squash court application from Chapter 2, A Sample Application. For this business, it might be very useful to have the Squash Court No. as a field in the G/L Entries to analyze.

The first step is to add the field to the G/L Entry table and make sure we have a table relation with the source table.

We have learned that the G/L Entries are generated from the general journal so we need to add this field there as well. This can be done with copy and paste.

The last step is to make sure we move the information from the journal to the ledger entry table. Like in our sample squash application, this is done in the Gen. Jnl.-Post Line Codeunit (12) only this codeunit has much more code.

We need to find the place where the G/L Entries are created and add our field there. This is done in the InitGLEntry function, as follows:

InitGLEntry()
...

GLEntry.INIT;
GLEntry."Posting Date" := GenJnlLine."Posting Date";
GLEntry."Document Date" := GenJnlLine."Document Date";
GLEntry."Document Type" := GenJnlLine."Document Type";
GLEntry."Document No." := GenJnlLine."Document No.";
...
GLEntry."Source Code" := GenJnlLine."Source Code";
//* Squash App. >>>
GLEntry."Squash Court No." := GenJnlLine."Squash Court No.";
//* Squash App. <<<
IF GenJnlLine."Account Type" = ...

This is all that is required in Microsoft Dynamics NAV to add a field to the financial posting process. Of course, it does not make sense to do this unless we use it, so a logical next step could be to add this new field to the Invoice Post. Buffer table from our previous example.

This shows how easy it is to combine solutions in Microsoft Dynamics NAV.