KB-212 – Accounting Engine Architecture¶

Knowledge Base ID: KB-212 Chapter: 3 - Posting Engine & Doc Factory Project: BLACK ERP Version: 0.3 Status: Draft Last Updated: 2026-06-26 Applies To: ADempiere 3.9.4

Purpose¶

This chapter explains how ADempiere transforms a completed business document into an accounting document ready for posting.

Once the Document Engine has completed the business transaction, the Posting Engine becomes responsible for creating the accounting representation of that document.

This is the point where the Accounting Engine actually begins.

Overview¶

Posting is not performed directly by business documents.

Instead, ADempiere creates an accounting wrapper around the document.

This wrapper is always a subclass of:

Doc

Examples include:

Doc_Invoice
Doc_Payment
Doc_AllocationHdr
Doc_InOut
Doc_Inventory
Doc_Movement
Doc_GLJournal

Each accounting class knows how to generate accounting entries for a specific business document.

High-Level Posting Flow¶

Business Document
        │
        ▼
Completed
        │
        ▼
Posting Process
        │
        ▼
Doc.post()
        │
        ▼
DocManager
        │
        ▼
Doc Factory
        │
        ▼
Instantiate Doc_*
        │
        ▼
Load Accounting Data
        │
        ▼
createFacts()
        │
        ▼
Fact
        │
        ▼
FactLine
        │
        ▼
FACT_ACCT

Posting Responsibilities¶

The Posting Engine is responsible for:

Loading the completed document
Determining the document type
Creating the correct Doc_* implementation
Executing accounting logic
Persisting accounting entries

Business documents do not perform accounting directly.

The Doc Factory¶

One of the most important architectural concepts is the Doc Factory.

Its responsibility is simple:

Given a business document...

Return the correct accounting implementation.

Example:

Business Document	Accounting Class
MInvoice	Doc_Invoice
MPayment	Doc_Payment
MAllocationHdr	Doc_AllocationHdr
MInOut	Doc_InOut
MInventory	Doc_Inventory

The rest of the Accounting Engine works only with the generic Doc abstraction.

Why the Factory Exists¶

Without a factory, every posting process would require multiple conditional statements.

Instead:

Document Type
        │
        ▼
Factory
        │
        ▼
Correct Doc_*

This keeps the Posting Engine independent from business document implementations.

Generic Posting Pipeline¶

Every accounting document follows the same execution pattern.

Load Document

↓

Instantiate Doc

↓

Load Accounting Schema

↓

Resolve Accounts

↓

Generate Facts

↓

Generate FactLines

↓

Persist FACT_ACCT

The document-specific implementation only customizes the accounting logic.

The pipeline itself never changes.

The Base Doc Class¶

All accounting implementations inherit from:

Doc

The base class provides common services such as:

Document metadata
Currency handling
Accounting schema loading
Posting date
Organization
Fact creation support
Account resolution helpers

Specialized accounting classes only implement the business-specific accounting rules.

Example: Allocation Posting¶

For payment allocations, the factory returns:

MAllocationHdr

↓

Doc_AllocationHdr

Our Mexican localization extends this standard flow by introducing:

Doc_AllocationHdr

↓

MXVATCashBasisEngine

↓

FactLines

The extension is inserted inside the accounting logic without modifying the Posting Engine itself.

Engineering Principles¶

The Posting Engine is generic.

Document-specific accounting is isolated inside each Doc_* implementation.

This architecture allows new accounting behaviors to be introduced with minimal impact on the rest of the ERP.

The Mexican VAT Cash Basis implementation follows this exact principle.

Next Chapter¶

Chapter 4 explores the internal structure of the Doc base class, including its lifecycle, helper methods, and responsibilities during posting.

Revision History¶

Version	Date	Description
0.3	2026-06-26	Added Posting Engine and Doc Factory architecture.