11.3 Data Process Model & Posting Routine Architecture

11.3 Data Process Model & Posting Routine Architecture

The posting pipeline is the computational heart of Microsoft Dynamics 365 Business Central. It is the engine that transforms transient transactional documents and staging journals into immutable, audited general ledger entries, subledger entries, item value entries, and register records. For the MB-820 exam, developers must master the Check -> Post -> Post-Batch architectural pattern, understand the division of responsibilities across core posting codeunits, and comprehend transaction consistency, in-memory temporary buffering, and the Posting Preview engine.

1. The Core Posting Architecture: Check -> Post Line -> Orchestrator

To ensure maintainability, scalability, and code reuse, Business Central decouples the posting pipeline into three discrete functional layers:

+-----------------------------------------------------------------------------------------+
|                                 THE POSTING PIPELINE                                    |
+-----------------------------------------------------------------------------------------+

   1. CHECK TIER (Validation)       ──▶  Codeunit 11 ("Gen. Jnl.-Check Line")
      - Validates dates, accounts,       Codeunit 21 ("Item Jnl.-Check Line")
        dimensions, and balances.        Codeunit 242 ("Item Jnl.-Check Line")

   2. POST-LINE TIER (Atomic Ledger)──▶  Codeunit 12 ("Gen. Jnl.-Post Line")
      - Creates G/L, Cust, Vend, Bank,   Codeunit 22 ("Item Jnl.-Post Line")
        VAT Entries & G/L Register.      Codeunit 23 ("FA Jnl.-Post Line")

   3. ORCHESTRATION TIER (Documents)──▶  Codeunit 80 ("Sales-Post")
      - Stages buffers, creates posted   Codeunit 90 ("Purch.-Post")
        invoices/shipments, calls C12/C22. Codeunit 231 ("Gen. Jnl.-Post Batch")

Why Posting is Decoupled:

• Reusability: Whether a general ledger transaction originates from an interactive General Journal page, an automated payroll API, a Sales Invoice posting (Sales-Post), or a Bank Reconciliation, it passes through the identical atomic posting engine: Codeunit 12 "Gen. Jnl.-Post Line".
• Fail-Fast Validation: The Check tier (Codeunit 11) executes all business and accounting validations before any physical database inserts occur, preventing partial posting failures.
• Transaction Encapsulation: The entire pipeline executes inside a single ACID-compliant database transaction. If an error occurs on line 50 of a 100-line invoice, SQL Server rolls back all modifications, preventing database corruption.

2. Core Posting Codeunits Deep Dive

Codeunit 11: Gen. Jnl.-Check Line

Gen. Jnl.-Check Line validates individual Gen. Journal Line records before posting. It executes the following critical checks:

1. Posting Date Validation: Verifies that "Posting Date" falls within the allowed date range defined in General Ledger Setup (Allow Posting From / Allow Posting To) and overridden in User Setup for the active user.
2. Account Validation: Verifies the "Account No." exists, is not Blocked, and has "Direct Posting" = true (if posted directly from a journal rather than a subledger).
3. Dimension Verification: Invokes DimensionManagement.CheckDimComb to confirm that table-level dimension combinations and dimension value posting rules (Code Mandatory, Same Code, No Code) are satisfied.
4. Balance & Currency Checks: Verifies foreign exchange rates, ensures currency factors are valid, and checks whether balancing accounts ("Bal. Account No.") are correctly defined.

Codeunit 12: Gen. Jnl.-Post Line

Gen. Jnl.-Post Line is the central transaction engine of Business Central. It operates as an atomic processor:

• G/L Entry Creation (Table 17): Inserts debit and credit G/L Entry records with sequential "Entry No." values, inheriting the line's Dimension Set ID.
• Subledger Posting: If "Account Type" is Customer, Vendor, or Bank Account, it creates corresponding subledger records (Cust. Ledger Entry, Vendor Ledger Entry, Bank Account Ledger Entry).
• Detailed Subledger Records: Inserts Detailed Cust. Ledg. Entry (Table 379) or Detailed Vendor Ledg. Entry (Table 380) records to track initial amounts, unrealized/realized currency gains and losses, and application history.
• VAT Calculation & Entries (Table 254): Calculates unrealized and realized sales/purchase tax, inserting VAT Entry records.
• Register Maintenance (Table 45 G/L Register): Opens a new G/L Register record on the first line of a transaction, tracks the starting "From Entry No.", and updates "To Entry No." upon transaction completion.

Codeunit 80: Sales-Post (Document Orchestrator)

Sales-Post coordinates the complex multi-table posting of sales documents:

1. Initial Validation: Verifies lines, quantities to ship/invoice, warehouse handling, and customer credit limits.
2. Posted Document Headers/Lines: Inserts immutable posted document records (Sales Shipment Header/Line, Sales Invoice Header/Line, Sales Cr.Memo Header/Line).
3. Inventory Dispatch: Builds Item Journal Line buffers and calls Codeunit 22 "Item Jnl.-Post Line" to decrement inventory and create Item Ledger Entry and Value Entry records.
4. G/L & Subledger Dispatch: Builds temporary Gen. Journal Line records and calls Codeunit 12 "Gen. Jnl.-Post Line" for revenue, accounts receivable, and tax posting.
5. Cleanup / Archiving: Deletes invoiced lines from Sales Line and Sales Header (or decrements "Quantity Shipped" / "Quantity Invoiced" for partial postings) and automatically archives the final document if configured.

3. In-Memory Temporary Tables & Performance Buffering

Posting routines stage data in memory using temporary record buffers before committing physical records to the database tier.

Mechanics of Record.IsTemporary()

• Declaring a record variable with var TempGenJnlLine: Record "Gen. Journal Line" temporary; (or calling TempRecord.Reset(); TempRecord.DeleteAll(); on temporary instances) instantiates the table buffer exclusively in Navision Server Tier (NST) RAM.
• No SQL Round-Trips: Operations such as TempRecord.Insert(), TempRecord.Modify(), and TempRecord.FindSet() execute in server memory without generating SQL TDS network traffic or table locks.
• Summing and Grouping: Posting routines accumulate tax amounts across lines by inserting records into TempVATAmountLine (Table 290). The code executes TempVATAmountLine.Get() or sums values in memory, and then generates consolidated G/L posting lines per VAT identifier.

// Example of in-memory buffering pattern used during posting orchestration
procedure PostInvoiceRounding(var SalesHeader: Record "Sales Header"; TotalAmount: Decimal)
var
    TempGenJnlLine: Record "Gen. Journal Line" temporary;
    GenJnlPostLine: Codeunit "Gen. Jnl.-Post Line";
    LineNumber: Integer;
begin
    LineNumber += 10000;
    TempGenJnlLine.Init();
    TempGenJnlLine."Line No." := LineNumber;
    TempGenJnlLine."Document Type" := TempGenJnlLine."Document Type"::Invoice;
    TempGenJnlLine."Document No." := SalesHeader."No.";
    TempGenJnlLine."Posting Date" := SalesHeader."Posting Date";
    TempGenJnlLine."Account Type" := TempGenJnlLine."Account Type"::"G/L Account";
    TempGenJnlLine."Account No." := SalesHeader."Invoice Rounding Account";
    TempGenJnlLine.Amount := TotalAmount;
    TempGenJnlLine."Dimension Set ID" := SalesHeader."Dimension Set ID";
    TempGenJnlLine.Insert(); // Staged in NST memory

    // Dispatch buffered temporary line to atomic posting engine
    GenJnlPostLine.RunWithCheck(TempGenJnlLine);
end;

4. Transaction Consistency, Commit Rules & Posting Preview

Transaction Consistency & The Explicit Commit Ban

In Business Central, database transactions are ACID compliant. A transaction begins implicitly upon the first write operation (Insert, Modify, Delete, LockTable) and commits when execution finishes without error.

• Strict Ban on Explicit Commit: Posting routines must never execute an explicit Commit() statement midway through posting. If a Commit were executed and a subsequent validation failed, the database would be left in an inconsistent, half-posted state with orphaned G/L or inventory entries.
• Error Rollback: If an unhandled error occurs (e.g., Error(ValidationErr) or TestField failure), the platform automatically issues a SQL rollback, unwinding all modifications across all tables made during that transaction.

The Posting Preview Architecture (Codeunit 19)

The Posting Preview feature allows users to inspect all G/L entries, VAT entries, Customer ledger entries, and Item ledger entries that would be generated prior to committing an actual post.

[ User clicks 'Preview Posting' ]
               │
               ▼
[ Codeunit 19 "Gen. Jnl.-Post Preview" initiates isolated background run ]
               │
               ▼
[ Event Subscribers intercept C12 / C22 inserts and write to Temporary Tables ]
               │
               ▼
[ Codeunit 19 throws controlled runtime Exception to force complete SQL Rollback ]
               │
               ▼
[ UI displays populated Temporary Ledger Tables in Posting Preview Page ]

1. Preview Mode Flag: Codeunit 19 "Gen. Jnl.-Post Preview" sets a global flag (PreviewMode := true) and executes the posting routine inside an isolated error-trapping scope.
2. Event Interception: Event subscribers in preview collector codeunits listen to OnAfterInsert... events in Codeunit 12 and Codeunit 22. Instead of inserting physical records to SQL, they copy the records into session temporary record buffers (TempGLEntry, TempCustLedgEntry, etc.).
3. Controlled Rollback: At the conclusion of the posting routine, Gen. Jnl.-Post Preview throws a special internal platform exception (PostPreviewException) that forces SQL Server to roll back the entire transaction completely.
4. UI Presentation: The temporary ledger buffers collected in memory are passed to the Posting Preview page, allowing the user to drill down into simulated accounting entries without altering physical database records.