Skip to content
ERPNext Data Model
Esc
navigateopen⌘Jpreview
On this page

Global architecture

How the 18 modules depend on each other, and the core hub entities almost every transaction touches.

Module dependency

The core hub

A hub entity is one with a high inbound reference count — many other DocTypes hold a link field pointing at it. That count is a blast-radius measure: renaming a field, tightening a validation, or changing the meaning of a hub entity ripples into every document that links to it, so these are the schema changes most expensive to get wrong. The 34 entities below all clear that threshold; the ranked list is in hub entities.

Each diagram groups one part of the hub by what actually calls it, with the fieldname that carries the reference labelled on the edge — see relationship notation for how to read the crow’s feet.

Company defaults

Company alone accounts for 39 of the 222 relationships below — more than any transaction. Every edge here is a }o--o| optional pointer from a per-company settings field (default_*, round_off_*, and similar) to the Account, Cost Center, Warehouse, or Finance Book a transaction should default to when none is specified explicitly. These are configuration, not transactional references: no document requires them, and in a single-company deployment most stay unset. A multi-company implementation is really just re-pointing this set of defaults per company.

Split across 2 diagrams so each stays legible; Company repeats in each.

The shared masters

Item, Customer, and Supplier are the party and product masters almost every transaction below references directly; their own outbound edges mostly point at the groupings and pricing that classify them. Warehouse, Cost Center, Project, Employee, Batch, Serial No, and Bank Account all resolve back to a Company, which is what makes them safe to scope per-company even though they are shared across every transaction type.

Split across 2 diagrams so each stays legible; Item, Customer, Supplier, and Company repeat in each.

The two ledgers

GL Entry and Stock Ledger Entry are append-only rows that transactions post, never edited directly. Both resolve back to the dimensions a report slices by — account, cost center, warehouse, project, company, fiscal year — which is why every ledger-based report is really a group-by over one of these two tables.

Order to cash

Sales Order, Delivery Note, and Sales Invoice form the outbound chain from commitment to delivery to billing. Each carries its own company for multi-company selling (represents_company marks an inter-company counterpart), its own pricing and warehouse defaults, and an inter_company_*_reference back to the matching document on the buying side — the same mechanism Purchase Order and Purchase Receipt use in the other direction.

Split across 2 diagrams so each stays legible; Customer, Company, and Warehouse repeat in each.

Procure to pay

Purchase Order, Purchase Receipt, and Purchase Invoice mirror the order-to-cash chain on the buying side, down to the same represents_company / inter_company_*_reference pattern for inter-company trades. Where they diverge from selling is warehouse fan-out: buying documents carry up to four distinct warehouse fields (set_warehouse, rejected_warehouse, supplier_warehouse, set_from_warehouse) because a single purchase can receive, reject, and redirect stock in one transaction.

Split across 2 diagrams so each stays legible; Supplier, Company, and Warehouse repeat in both.

Settlement

Payment Entry closes out invoices from either side of the business: one paid_from account and one paid_to account, optionally tied to a specific bank account rather than the company’s default. It is the smallest of the transaction clusters because settlement genuinely needs less context than the documents it settles.

Make and hold

BOM, Work Order, Stock Entry, and Asset are the manufacturing and fixed-asset side of the hub. A BOM defines what a Work Order builds; a Work Order can consume or produce through a Stock Entry, which is also the general-purpose stock-movement document referencing whichever sales, purchase, or delivery record triggered it. Asset sits apart from the manufacturing chain but shares the same warehouse and cost-center vocabulary.

Split across 2 diagrams so each stays legible; Item, Company, and Warehouse repeat in both.

34 hub entities, 222 direct relationships shown across 12 focused diagrams.

Was this page helpful?