Skip to content

KB-212 – Accounting Engine Architecture

Knowledge Base ID: KB-212
Chapter: 7 - MAcctSchema: The Accounting Schema Model
Project: BLACK ERP
Version: 0.7
Status: Draft
Last Updated: 2026-06-26
Applies To: ADempiere 3.9.4


Purpose

This chapter introduces the MAcctSchema class, one of the most important components of the Accounting Engine.

Unlike the previous chapters, this document is based on the actual source code of ADempiere 3.9.4.

MAcctSchema represents the Accounting Schema used during every posting process and acts as the central configuration object for the General Ledger.

It does not generate accounting entries.

Instead, it provides the accounting rules used by the Posting Engine.


Source File

source/base/src/org/compiere/model/MAcctSchema.java

Package:

org.compiere.model

Class Hierarchy

PO
 │
 ▼
X_C_AcctSchema
 │
 ▼
MAcctSchema

The hierarchy follows the standard ADempiere persistence model.

  • PO provides persistence services.
  • X_C_AcctSchema is the generated model from the database dictionary.
  • MAcctSchema adds business logic.

This means the class is responsible for behavior, not persistence.


Primary Responsibility

MAcctSchema represents the accounting configuration used by the Posting Engine.

It contains configuration such as:

  • Currency
  • Costing Method
  • Costing Level
  • GAAP
  • Commitment Type
  • Period Control
  • Posting Options

It does not contain General Ledger account definitions.

Those are stored in specialized accounting tables.


Architectural Position

AD_Client
      │
      ▼
AD_ClientInfo
      │
      ▼
MAcctSchema
      │
      ▼
Posting Engine
      │
      ▼
Doc
      │
      ▼
Fact

The Accounting Schema is loaded before any accounting document is created.


Static Factory Methods

The class exposes several static helper methods.

The two most important are:

MAcctSchema.get(...)

and

MAcctSchema.getClientAcctSchema(...)

Instead of creating new objects directly, the Accounting Engine retrieves schemas through these factory methods.

This centralizes object creation and cache management.


Lazy Loading Pattern

One of the first architectural patterns found in the source code is Lazy Loading.

Conceptually:

Request Schema

      │

      ▼

Is Schema Cached?

      │

 ┌────┴─────┐
 │          │
 ▼          ▼

Yes        No
 │          │
 │          ▼
 │     Load From Database
 │          │
 │          ▼
 │     Store In Cache
 │          │
 └──────► Return Object

This minimizes database access during posting.


Cache Architecture

The implementation defines two independent caches.

CCache<Integer, MAcctSchema>

Caches a single Accounting Schema.


CCache<Integer, MAcctSchema[]>

Caches all schemas belonging to a client.

This avoids repeated database lookups during accounting operations.


Multi-Schema Support

An important design decision becomes visible in:

getClientAcctSchema(...)

The method returns:

MAcctSchema[]

instead of

MAcctSchema

This confirms that ADempiere was designed to support multiple Accounting Schemas simultaneously.

Example:

Client

 │

 ├── Primary Ledger

 ├── Fiscal Ledger

 ├── IFRS Ledger

 └── Management Ledger

The Posting Engine can therefore generate accounting entries for more than one ledger.


Client Entry Point

The source code reveals that Accounting Schemas are obtained through the client configuration.

Conceptually:

AD_Client

↓

AD_ClientInfo

↓

C_AcctSchema1_ID

↓

MAcctSchema

This makes AD_ClientInfo the gateway to the accounting configuration.


Constructor Defaults

When a new Accounting Schema is created, the constructor initializes several default values.

Examples include:

  • Automatic Period Control
  • Standard Costing
  • Client-Level Costing
  • International GAAP
  • Accrual Accounting
  • No Commitment Control
  • Default Separator

This ensures every new schema starts with a valid configuration before being persisted.


What MAcctSchema Does NOT Do

A common misconception is assuming this class stores accounting accounts.

It does not.

There are no Chart of Accounts definitions inside MAcctSchema.

Instead, account definitions are resolved through specialized accounting metadata.

Examples include:

  • C_AcctSchema_Default
  • MProductAcct
  • MBPartnerAcct
  • MTax
  • MCharge

These components will be analyzed in the following chapters.


Engineering Notes

Several design patterns become evident in this implementation.

  • Active Record
  • Factory Method
  • Lazy Loading
  • Object Cache
  • Configuration Object

The class focuses entirely on configuration and object lifecycle.

It does not perform posting logic.


BLACK ERP Engineering Notes

During the Mexican VAT Cash Basis implementation, no modifications were required to MAcctSchema.

The localization reuses the Accounting Schema exactly as provided by the standard Accounting Engine.

This confirms that the localization extends posting behavior without altering the accounting configuration model.


Related Classes

MClientInfo

↓

MAcctSchema

↓

Doc

↓

Fact

↓

FactLine

Key Takeaways

  • MAcctSchema represents the Accounting Schema.
  • It stores accounting configuration, not accounting entries.
  • It supports multiple ledgers per client.
  • It implements Lazy Loading and Cache patterns.
  • It is loaded before any posting operation begins.
  • It acts as the configuration foundation of the entire Accounting Engine.

Next Chapter

Chapter 8 explores the accounting metadata that actually stores General Ledger accounts, including:

  • C_AcctSchema_Default
  • MProductAcct
  • MBPartnerAcct
  • MTax
  • MCharge

These objects provide the accounts later resolved by Doc.getAccount().


Revision History

Version Date Description
0.7 2026-06-26 First source-code-based documentation of MAcctSchema, including cache architecture, lazy loading, multi-schema support and engineering analysis.