Concepts
Entity kinds, relationship notation and what the diagrams do and do not show.
Every ERPNext entity is a DocType — a table definition stored as JSON in the source tree and
materialised as a MariaDB/Postgres table named tab<DocType Name>. This document reflects the
JSON definitions of ERPNext v16.29.0,
so it is the authoritative schema for that release, not a reconstruction from a live database.
See source version for the exact commit and the apps in scope.
Entity kinds
| Mark | Kind | Meaning |
|---|---|---|
| M | Master | Reference data with an independent lifecycle. Created once, referenced many times. Example: Customer, Item, Account. |
| T | Transaction | A submittable business document with a docstatus lifecycle (0 = Draft, 1 = Submitted, 2 = Cancelled). Once submitted it is immutable and posts ledger entries. Example: Sales Invoice, Stock Entry, Work Order. |
| L | Ledger / derived | An append-only table written by transactions rather than entered by a user. Never edited directly; rebuilt by reposting. Example: GL Entry, Stock Ledger Entry, Bin. |
| C | Child table | A row set owned by exactly one parent document. Has no independent existence — deleting the parent deletes the rows. Example: Sales Invoice Item. |
Relationship notation
| Mermaid | Field type | Meaning |
|---|---|---|
A }o--|| B |
Link, required | Each A must reference exactly one B; a B may be referenced by many A. |
A }o--o| B |
Link, optional | Same, but the reference may be null. |
A ||--o{ B |
Table / Table MultiSelect | Composition. A owns zero or more B rows. |
| (text only) | Dynamic Link | Polymorphic. The target doctype is itself stored in another field, so the edge cannot be drawn statically. See the polymorphic link index. |
Every relationship carries the fieldname as its label, so an edge maps directly onto a column. Entities marked (fw) belong to the Frappe framework rather than ERPNext (framework entities), and (payments) marks the one doctype owned by the separate frappe/payments app.
A note on diagram completeness
Per-module diagrams draw only edges whose both endpoints sit inside that diagram, and large modules are split into readable chunks. No relationship is lost: the relationship index lists every link and table field in the entire scope, and each entity’s own reference table lists all of its outgoing edges.
Where to next
The data model in brief
Universal columns, the three ledger patterns and the transaction chain.
Modules
All 18 modules, their diagrams and their entity reference.
GST compliance (India)
How the separate India Compliance app layers GST on top of this model — entity shapes, validation rules and the e-Invoice/e-Way Bill/GSTR workflows.