🎓 Series Recap
Before building the capstone, make sure the concepts below are familiar — each references the part that covers it.
This project builds out the Lab Sample example first introduced in Part 7, taking it from a foreshadowed sketch to a fully specified custom Frappe app — master data, transactions, ERPNext integration, and a workflow — using the exact same architecture Part 7 taught. It also leans on the accounting theory behind invoicing from Invoice vs Payment: The Complete ERP Accounting Architecture and the Accounting to ERP curriculum.
📝 Project Brief
The goal: build a Laboratory Management extension to ERPNext as a proper custom Frappe app — never as core edits — covering master data, transactions, ERPNext integration, and a workflow, exactly following the app architecture from Part 7. A diagnostic lab needs to register patients, capture samples, run tests, record and approve results, issue reports, and bill for all of it — without the custom app reinventing anything ERPNext already does well.
Master Data
- Patient — the person being tested
- Test — a billable lab test definition
- Sample Type — blood, urine, swab, etc.
- Department — the lab section running the test (hematology, microbiology, …)
- Doctor — the referring/ordering physician
Transactions
- Lab Request — the order for one or more tests on a patient
- Sample Collection — the physical sample taken against a request
- Test Assignment — routing a sample/test pair to a technician
- Result Entry — the raw result value recorded by the technician
- Result Approval — sign-off by a supervising role
- Lab Report — the finished, patient-facing document
Integration
- Customer — every Patient is billed as an ERPNext Customer
- Item — every billable Test maps to an Item
- Sales Invoice — generated automatically off a released Lab Report
- Payment Entry — settles that invoice through the standard AR flow
- Employee — every collection, assignment, and approval step references one
- Accounts — the GL Entry rows the Sales Invoice ultimately produces
🧬 DocType Design
Six transaction DocTypes carry the workflow. A couple reuse the naming-series convention from Part 4 — e.g. LAB-REQ-.YYYY.-.##### for Lab Request and LAB-RPT-.YYYY.-.##### for Lab Report — so records sort chronologically and stay human-readable.
| DocType | Key fields | Child table |
|---|---|---|
Lab RequestLAB-REQ-.YYYY.-.##### | patient (Link → Patient), doctor (Link → Doctor), requested_tests | Lab Request Test — one row per requested Test |
| Sample Collection | lab_request (Link → Lab Request), sample_type (Link → Sample Type), collected_by (Link → Employee), collection_datetime | — |
| Test Assignment | sample (Link → Sample Collection), test (Link → Test), assigned_to (Link → Employee) | — |
| Result Entry | test_assignment (Link → Test Assignment), result_value, result_unit, reference_range, flagged (Check) | — |
| Result Approval | result_entry (Link → Result Entry), approved_by (Link → Employee), approval_datetime | — |
Lab ReportLAB-RPT-.YYYY.-.##### | patient (Link → Patient), lab_request (Link → Lab Request), tests, status | Lab Report Test — rows pulled from the linked Result Entry records |
Every Link field here is the same "reference, don't duplicate" pattern from Part 1's master/transaction table split and the full relationship model in Part 4: a Result Entry doesn't copy patient details, it links back through Test Assignment → Sample Collection → Lab Request → Patient.
🔗 ERPNext Integration Map
The new DocTypes link back into ERPNext core via ordinary Link fields, following that same pattern as Part 7's core-linking section: Patient.customer → Customer (a lab patient is billed as an ERPNext Customer), each billable Test maps to an Item, Lab Report.company → Company, and every collection, assignment, and approval step references an Employee.
Customer
Item
Company
Employee
Patient
Sample
Lab Report
🔄 Workflow
Each transition is gated to a specific role, the same state/role modeling covered in Part 6's workflow deep-dive:
| Current state | Role allowed | Action | Next state |
|---|---|---|---|
| Request | Front Desk | Collect Sample | Sample Collected |
| Sample Collected | Lab Technician | Begin Testing | Testing |
| Testing | Lab Technician | Enter Result | Result Entered |
| Result Entered | Lab Supervisor | Verify | Verified |
| Verified | Pathologist | Approve | Approved |
| Approved | System / Front Desk | Release Report | Report Released |
💳 Billing Automation (Level 3 Integration in Action)
A doc_events hook — the same mechanism covered in Part 7's hooks & events deep-dive — fires on Lab Report's on_submit. It creates a Sales Invoice for the linked Customer, with one Sales Invoice Item row per Test (each Test's linked Item), and links back to the Lab Report through a reference field so the two documents stay traceable to each other.
That final step is the same mechanics as the GL Entry generation walkthrough in Part 5 — the Sales Invoice's own submit is what actually creates the ledger postings, not the lab app. This keeps billing entirely inside ERPNext's standard AR flow rather than the lab app reinventing invoicing, which is exactly the "invoice = obligation, don't duplicate the concept" argument applied to a real custom app: the Lab Report records that a service was performed; the Sales Invoice, a separate and reusable ERPNext document, records what is owed for it.
🏬 Second Scenario: Retail (ABC Electronics Ltd.)
Running in parallel on the purchasing side, Supplier → Purchase Order → Purchase Receipt → Purchase Invoice → Payment follows the identical shape — both chains automatically updating Stock and Accounting per the mechanics detailed in Part 5, without either team touching the other's documents directly.
🏭 Third Scenario: Manufacturing
Every module gets involved in this one chain — Selling, Manufacturing, Stock, and Accounting — the same cross-module shape explored in Part 3's Manufacturing module section.
🖼️ Illustrative UI Walkthrough (Not Real Screenshots)
| Screen | What it demonstrates |
|---|---|
| Lab Request form | Link fields to Patient and Doctor resolving and auto-filling related data as they're selected |
| Sample Collection list view | A list filtered by status, showing samples still awaiting collection or testing |
| Result Entry form | Inline validation via a Server Script — e.g. flagging a result outside its reference range |
| Workflow action buttons | The available action changing per state, exactly as mapped in the Workflow table above |
| Auto-created Sales Invoice | The Level 3 integration payoff — billing appearing automatically from the on_submit hook |
| Workspace with the Lab Management module icon | The Level 1 integration payoff — the custom app sitting alongside core modules in the Desk sidebar |
🏛️ Final Architecture Slide
One diagram meant to summarize the entire nine-part series — every layer this course has walked through, stacked in the order a request actually travels:
USER
ERPNext UI
Frappe Framework
Modules
DocTypes
API
Business Logic
Accounting
Stock
HR
MariaDB
Reports / BI
Management
💻 Final Cheat Sheet
Architecture
Frappe → ERPNext → Apps → Modules → DocTypes → Database
Core Concepts
DocType, Document, Field, Link, Child Table, Workflow, Role, Permission, Hook, API
Business Concepts
Customer, Supplier, Item, Warehouse, Account, Employee, Sales, Purchase, Stock, Accounting
Developer Concepts
Bench, App, Custom App, Hooks, Controller, Client Script, Server Script, REST API, Migration, Patch, Fixture
Deployment
Nginx, Redis, MariaDB, Supervisor, SSL, Backup, Worker, Scheduler
🏁 Series Complete
Across nine parts, this series took the reader from an ERPNext beginner through Installation, System Setup, Users & Roles, Modules, DocTypes, Database, Business Workflows, Customization, Custom Apps, and API Integration — and now, with this capstone, a complete custom Frappe app built and integrated end to end. This is the journey this series promised in Part 1, restated one last time:
That is the whole series. Thank you for following it from Part 1 through the capstone.