The data model in brief
Universal columns, the three ledger patterns, the transaction chain and the polymorphic party pattern.
Universal columns
Every entity — master, transaction and child alike — inherits this envelope:
| Column | Purpose |
|---|---|
name |
Primary key. A string, not an integer. Its shape comes from the naming rule (naming series, a field value, a hash, or a format string). All foreign keys store this string. |
owner, creation |
Created-by user and timestamp. |
modified_by, modified |
Last-modified user and timestamp. Used for optimistic locking. |
docstatus |
0 Draft / 1 Submitted / 2 Cancelled. Meaningful on transactions. |
idx |
Sort position — the row order within a parent, for child tables. |
parent, parenttype, parentfield |
Child tables only. The owning document’s name, its doctype, and the Table fieldname it sits under. This triple is the child→parent foreign key. |
Because primary keys are strings, a Link field stores the target’s name directly. There are no
surrogate integer IDs and no database-level foreign key constraints — referential integrity is
enforced in the application layer.
The three ledger patterns
ERPNext’s financial and inventory truth lives in append-only ledger tables written by submitted transactions. Understanding these three explains most of the Accounts and Stock module:
| Ledger | Written by | Records |
|---|---|---|
GL Entry |
Every accounting transaction | Double-entry debit/credit against an Account, tagged with Company, Cost Center, and any Accounting Dimension. |
Stock Ledger Entry |
Every stock movement | Quantity and valuation change for an Item in a Warehouse, optionally per Batch/Serial No. |
Payment Ledger Entry |
Invoices and payments | Party-wise outstanding balance, driving receivables/payables ageing. |
Ledger rows are never updated in place. A cancellation writes reversing entries; a correction is a
new document. This is why is_return, return_against and amended_from appear throughout.
The transaction chain
ERPNext commonly connects documents through three business flows. Solid arrows show the usual create-from path, dotted arrows show optional bypasses or cross-flow paths, and labelled lines without arrowheads show references rather than document creation. These are representative, not exhaustive: source references may be stored on a document header or on its child rows.
Order to Cash
Procure to Pay
Plan to Produce
Cross-flow integration
Material Request purpose determines whether demand enters manufacturing or procurement.
The polymorphic party pattern
Address and Contact are not linked from Customer or Supplier directly. Instead they own a
Dynamic Link child table holding link_doctype + link_name, so one address can serve a
Customer, a Supplier and a Company simultaneously. The same pattern appears in Payment Entry
(party_type + party) and in every reference_doctype + reference_name pair. the polymorphic link index lists them all.