ERPNext Modules & Business Workflows

💰 Accounting Module

Purpose: Accounting is the books of record for the entire ERPNext installation — every other module's transactions eventually translate into a posting here, so it's the one module every implementer needs to understand even if they never touch a Sales Order.

Sales side: Order to Cash

Purchase side: Procure to Pay

Key child tables: Sales Invoice Item, Purchase Invoice Item, Journal Entry Account, Payment Entry Reference — the last of these is what links a Payment Entry back to the specific invoice(s) it settles.

Accounting/stock impact: this module is the accounting impact — every submitted Sales Invoice, Purchase Invoice, Payment Entry, and Journal Entry writes one or more balanced debit/credit rows to GL Entry.

Connects to: every other module in this article eventually posts here — see Selling, Buying, Manufacturing, HR & Payroll, and Assets below, and the full picture in Complete Module Interconnection.

🛒 Selling Module

Purpose: Selling covers everything from a qualified opportunity to a paid invoice — the quote-to-cash cycle for customers.

Master data: Customer, Customer Group, Territory, Sales Person, Item, Price List, Sales Taxes and Charges Template.

Key child tables: Quotation Item, Sales Order Item, Delivery Note Item, Sales Invoice Item — each new document typically pulls its rows from the previous one so item, price, and quantity stay traceable end to end.

Accounting/stock impact: Delivery Note reduces stock quantity and posts a stock-value GL entry; Sales Invoice posts revenue and receivable GL entries.

Connects to: Stock (Delivery Note), Accounting (Sales Invoice, Payment Entry), and CRM (Lead, Opportunity).

📦 Buying Module

Purpose: Buying is the procure-to-pay cycle — sourcing, ordering, receiving, and paying suppliers.

Master data: Supplier, Supplier Group, Item, Buying Price List.

Key child tables: Material Request Item, Purchase Order Item, Purchase Receipt Item, Purchase Invoice Item.

Accounting/stock impact: Purchase Receipt increases stock quantity and posts a stock-value GL entry; Purchase Invoice posts expense/asset and payable GL entries.

Connects to: Stock (Purchase Receipt raises quantity via a Stock Ledger Entry), Accounting (Purchase Invoice, Payment Entry), plus its own Supplier and Item master data shared with every other module.

📊 Stock Module

Purpose: Stock tracks inventory quantity and valuation across every warehouse, and is the single source of truth every Selling, Buying, and Manufacturing document ultimately updates.

Key documents: Item, Item Group, Warehouse, Stock Entry, Stock Reconciliation, Delivery Note, Purchase Receipt, Serial Number, Batch, Bin, Stock Ledger Entry.

Key child tables: Stock Entry Detail, Purchase Receipt Item, Delivery Note Item, Stock Reconciliation Item.

Stock Ledger Entry is the append-only movement log every stock-affecting document writes to — one row per item/warehouse movement, in quantity and value, forward in time. Current on-hand quantity in Bin and every valuation report are derived from summing this log, not stored independently — the same "log first, derive state" pattern the ledger itself follows on the accounting side. The exact mechanics of how Stock Ledger Entry and GL Entry stay in sync are covered in Part 5's Stock Ledger deep dive.

Accounting/stock impact: Stock is the quantity/valuation record; its value movements post matching GL entries whenever a stock account is involved (perpetual inventory).

Connects to: Selling, Buying, Manufacturing, and Accounting.

🏭 Manufacturing Module

Purpose: Manufacturing converts raw materials into finished goods through a defined recipe and shop-floor process.

Key documents: Item, BOM, Workstation, Operation, Routing, Work Order, Job Card, Material Request, Stock Entry.

A BOM's recipe lines live in its child table, BOM Item — one row per raw material/component with quantity, rate, and operation. Other key child tables: Work Order Item, Job Card Time Log.

A multi-level BOM happens when a BOM Item row itself references an Item that has its own BOM — manufacturing the top-level finished item can then cascade into manufacturing its sub-assemblies first, each with its own Work Order and Job Card chain.

Accounting/stock impact: raw material consumption and finished-goods receipt both post Stock Entry movements that carry matching GL entries when a perpetual-inventory Company is used.

Connects to: Stock (every material transfer and finished-goods receipt) and Accounting (work-in-progress and finished-goods valuation).

🤝 CRM Module

Purpose: CRM manages the pre-sales relationship — capturing interest and qualifying it before it becomes a Selling transaction.

Key documents: Lead, Opportunity, Customer, Contact, Address, Communication, Activity.

Key child tables: Opportunity Item, Contact Email, Contact Phone, Dynamic Link (used on Contact/Address to attach to a Lead, Customer, or Supplier interchangeably).

Accounting/stock impact: none directly — CRM documents don't post GL or stock entries; they exist entirely upstream of the first billable transaction.

Connects to: Selling — an Opportunity converts into a Quotation and a Lead converts into a Customer, handing off into the quote-to-cash flow.

📋 Projects Module

Purpose: Projects tracks billable and internal work as tasks and logged time, connecting labor to both cost centers and customer billing.

Key documents: Project, Task, Timesheet, Activity Type, Employee, Cost Center, Sales Invoice.

Key child tables: Timesheet Detail (one row per logged time block, linked to a Task and Activity Type), Project Task.

Accounting/stock impact: none directly from Project/Task/Timesheet themselves; impact arrives only once billable hours are pulled into a Sales Invoice, which then posts normal revenue GL entries.

Connects to: HR & Payroll (Timesheet references Employee) and Accounting (via billing).

🧑‍💼 HR & Payroll Module

Purpose: HR & Payroll manages the employee lifecycle — attendance, leave, and ultimately calculating and posting salary.

Key documents: Employee, Department, Designation, Employee Grade, Attendance, Leave Application, Leave Allocation, Salary Structure, Salary Slip, Payroll Entry, Expense Claim.

Key child tables: Salary Detail (earnings/deductions rows on both Salary Structure and Salary Slip), Leave Allocation ledger rows, Expense Claim Detail.

Accounting/stock impact: a submitted Payroll Entry posts salary expense and payable/bank GL entries in bulk across every included Salary Slip.

Connects to: Projects (Timesheet references Employee) and Accounting (Payroll Entry, Expense Claim).

🏗️ Asset Module

Purpose: Assets manages the fixed-asset lifecycle from acquisition through depreciation to eventual movement or disposal.

Master data: Asset Category, Asset. Key child tables: Asset Finance Book (depreciation method/rate per book), Asset Depreciation Schedule.

Accounting/stock impact: each scheduled depreciation run posts a Journal Entry that debits Depreciation Expense and credits Accumulated Depreciation for that period, gradually reducing the asset's net book value on the balance sheet without any cash movement.

Connects to: Accounting — Assets is one of the modules whose entire financial impact is periodic, scheduled GL postings rather than transaction-triggered ones.

🔍 Quality Module

Purpose: Quality gates whether goods moving in or out, or produced on the shop floor, meet defined conformance criteria before the surrounding transaction is allowed to proceed.

Key documents: Quality Inspection, Quality Goal, Quality Procedure, Non Conformance, Quality Action.

Key child tables: Quality Inspection Reading (one row per parameter measured against a specification), Quality Procedure Process.

A Quality Inspection can be configured as mandatory before a Purchase Receipt is submitted (incoming inspection) or before a Delivery Note is submitted (outgoing inspection), and can equally gate a Manufacturing Job Card's finished-goods step — in each case the transaction simply cannot be submitted until a linked, passed Quality Inspection exists.

Accounting/stock impact: none directly — Quality Inspection itself posts no GL or stock entries; its effect is procedural, blocking or permitting the stock-moving document it's attached to.

Connects to: Stock, Buying, Selling, and Manufacturing.

🎧 Support Module

Purpose: Support handles post-sales customer service — logging, assigning, and resolving issues raised by existing customers.

Key documents: Issue, Customer, Contact, Communication, Service Level Agreement, Assignment, Support Ticket.

Key child tables: ToDo rows created per assignment, Communication link rows tying emails/notes back to the Issue.

Accounting/stock impact: none directly — Support is a service-tracking layer with no GL or stock postings of its own.

Connects to: CRM and Selling — every Issue links back to the same Customer master record those modules also reference.

🕸️ Complete Module Interconnection

Zooming out from each module's individual flow, the same shape repeats everywhere: a pre-sales or planning module feeds a transaction module, and every transaction module eventually drains into Stock and/or Accounting.

🗺️ What's Next

This article expanded Part 1's compressed Core Modules at a Glance table and flagship document flows into a full module-by-module reference — master data, document flow, child tables, and accounting/stock impact for all eleven modules. From here, Part 4: DocTypes & Database Relationships (erpnext-doctypes-database-relationships.html) goes underneath these documents to the actual database structure — how a DocType becomes a table, how child tables relate to their parents, and how every Link field shown here as an arrow is really a foreign-key-style reference in MariaDB.