π§π© What This Case Study Series Is
This is Part 1 of a 4-part Bangladesh implementation case study, built as a practical companion to the existing 9-part ERPNext Beginner to Intermediate course. That course teaches the architecture, modules, database design, permissions, and customization mechanics of ERPNext in general. This series takes those concepts and runs them through a realistic, end-to-end implementation for two fictional Bangladeshi companies β a hospital and a real estate/construction firm β so every concept is grounded in a concrete requirement instead of an abstract example.
Where the beginner course explains how ERPNext works, this series explains how to run the project of making ERPNext work for a specific business: gathering requirements, deciding what to configure versus build, structuring the environment pipeline, training users, and β in Parts 2 and 3 β walking through the actual hospital and real estate workflows in detail.
π’ The Two Companies
Dhaka Care Medical & Hospital Ltd.
| Location | Dhaka, Bangladesh |
| Type | Private hospital and diagnostic center |
| Departments | OPD, Emergency, IPD, ICU, CCU, OT, Pharmacy, Laboratory, Radiology, Blood Bank, Ambulance, Nursing |
Dhaka Skyline Properties & Construction Ltd.
| Location | Dhaka, Bangladesh |
| Type | Real estate development and construction |
| Business lines | Land acquisition, apartment/commercial development, construction, subcontracting, apartment sales and installment collection |
π§ The Implementation Mindset
The single biggest mistake in an ERP implementation is starting from the database β opening the DocType list and asking "which of these tables do we need?" A real implementation starts from the business process, walks it end to end with the people who actually do the work, and only then asks which ERPNext module, DocType, or customization maps onto each step. For Dhaka Care Medical & Hospital, the actual starting point of requirements gathering is a hospital's admission process β who decides a patient needs a bed, who allocates it, what has to be true before billing can start β not the fields on a Patient DocType. For Dhaka Skyline Properties & Construction, it's the apartment booking-to-handover process β how a buyer reserves a unit, pays a down payment, and enters an installment schedule β not the fields on a Sales Order. The DocType is where the requirement eventually lands; it is never where the requirement starts.
This chain is the backbone of the entire series: every workflow described in Parts 2 and 3 is walked through in exactly this order β business process first, ERPNext mapping last.
β οΈ Version & Environment Matrix
| Item | Value | Note |
|---|---|---|
| ERPNext Version | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Frappe Version | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Python Version | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Node.js Version | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Database | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Redis Version | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| OS | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
| Deployment Target | Set explicitly per project | Do not assume β confirm against the actual target environment before implementation; ERPNext/Frappe versions change schemas, commands, and dependencies. |
Note the "Database" row deliberately does not name MariaDB or PostgreSQL as a fixed answer here β which database engine is actually supported, and how it behaves, is itself version-dependent and must be verified against the target ERPNext/Frappe release rather than assumed from this series.
π Development β Staging β Production Pipeline
Both companies' custom work β hospital DocTypes, real estate/construction DocTypes, and any integrations β should move through the same disciplined pipeline rather than being edited directly on a live site:
- Developer β writes and tests changes locally against a development site.
- Git β every change to a custom app is a tracked, reviewable commit, never an unversioned live edit.
- Development β a shared dev site where changes are integrated and sanity-checked.
- CI β automated checks run on every push (linting, basic test execution) before a change is considered mergeable.
- Testing β scripted and manual tests validate the specific business logic changed.
- Staging β a production-like environment, seeded with realistic (not real) data.
- UAT β actual hospital or real estate staff verify the change against their real workflow.
- Approval β a named sign-off gate before anything reaches production.
- Production β the live site, changed only through this pipeline.
The hospital and real estate custom logic should each live in their own separate Frappe app (e.g. a "hospital" app and a "realestate" app) rather than inside ERPNext core, for the same reason any framework discourages editing vendor code directly: core upgrades would silently overwrite or conflict with in-place changes, custom logic wouldn't be independently versioned or deployable, and one company's customization could accidentally affect the other. Part 4, Custom Development, DevOps & Production, covers the full mechanics of building, packaging, and deploying these two apps; the general pattern it builds on is documented in the beginner course's Building a Custom Frappe App.
β The Six-Question Training Framework
Every major feature in Parts 2 and 3 β every screen a hospital receptionist or a real estate sales officer will actually touch β is introduced using the same six questions. Asking all six, in order, is what turns a feature walkthrough into something a non-technical user can actually learn from:
| Question | What it establishes |
|---|---|
| WHO | Who uses it β the role or job function that touches this feature |
| WHAT | What the feature/document actually is |
| WHY | Why the business needs it β what breaks or goes untracked without it |
| WHEN | At what point in the process it gets used |
| WHERE | Where it's found in ERPNext β module, workspace, or custom app |
| HOW | How it's configured or used, step by step |
Applied to one concrete example from each company:
| Question | Admission (hospital) | Property Booking (real estate) |
|---|---|---|
| WHO | Receptionist / Ward Nurse | Sales Officer |
| WHAT | The Admission document | The Property Booking document |
| WHY | Formally starts inpatient billing and bed allocation | Reserves a specific unit and formally starts the buyer's payment/installment obligation |
| WHEN | After a doctor decides IPD care is needed | After a buyer confirms interest and pays a booking amount |
| WHERE | Hospital custom module, linked from the Patient/Appointment record | Real Estate custom module, linked from the Property/Unit record |
| HOW | Created against a Patient, assigns a Bed/Ward, and is later linked to Discharge and Billing | Created against a Unit and a Customer, records the booking amount, and is later linked to the Installment Schedule and Sales Invoice |
This exact six-question pattern is reused for every major feature introduced in Part 2 (Hospital Management) and Part 3 (Real Estate & Construction) β once it's familiar here, every later walkthrough in the series follows the same shape.
π Field-Level Training Methodology
Below the feature level, the series documents individual fields using a second consistent table shape: Field | Type | Required? | Who enters? | When? | Why? | Example | Related DocType. This is the format Parts 2 and 3 use for every hospital and real estate DocType field they walk through.
As a worked, generic example using core ERPNext's Customer DocType β illustrative field names and Bangladesh-context example values, not a guarantee of the exact field list on any specific installed version (Customer's fields, like any DocType's, are subject to change between releases and should be confirmed via Customize Form on the actual target site):
| Field | Type | Required? | Who enters? | When? | Why? | Example | Related DocType |
|---|---|---|---|---|---|---|---|
customer_name | Data | Yes | Sales/Front-office staff | At first record creation | Primary identifier for every downstream transaction | Rahman Traders | Customer |
customer_group | Link | Yes | Sales staff, per company policy | At creation | Drives pricing rules and reporting segmentation | Corporate | Customer Group |
territory | Link | Yes | Sales staff | At creation | Used for territory-based sales reporting and targets | Dhaka | Territory |
customer_type | Select | Yes | Sales staff | At creation | Distinguishes Company vs Individual for compliance and reporting | Company | Customer |
tax_category | Link | No (as applicable) | Accounts staff | Before the first taxable invoice | Determines which tax template applies at billing time | Registered (example placeholder) | Tax Category |
default_currency | Link | No | Accounts staff | At creation, if not BDT | Overrides the company's base currency for this customer's transactions | BDT | Currency |
Parts 2 and 3 apply this exact table shape to hospital DocTypes (Patient, Admission, Lab Order, β¦) and real estate DocTypes (Property, Unit, Booking, Installment Schedule, β¦).
𧩠Which ERPNext Base Modules Both Companies Share
Before either company needs a single line of custom code, a large share of their requirements are met by ERPNext's existing base modules β full detail on each module's purpose, master data, and document flow is in the beginner course's module-by-module tour. This table summarizes how much of each module each company actually uses:
| Module | Used by Hospital | Used by Real Estate |
|---|---|---|
| Accounting | Yes | Yes |
| Selling | Partial (patient billing, not classic quote-to-cash) | Yes |
| Buying | Yes (pharmacy/medical supplies procurement) | Yes (construction materials procurement) |
| Stock | Yes (pharmacy, lab consumables, blood bank) | Partial (construction materials, not retail-style inventory) |
| CRM | No (usually) | Yes (lead-to-booking) |
| Projects | Partial (facility/equipment projects) | Yes (construction project tracking) |
| Assets | Yes (medical equipment) | Yes (heavy equipment, vehicles) |
| HR | Yes | Yes |
| Payroll | Yes | Yes |
| Quality | Partial (lab/diagnostic quality checks) | Partial (construction quality inspection) |
| Support | Partial (patient complaints) | Partial (post-handover buyer support) |
| Manufacturing | No | No (unless the reader's real project needs it) |
π§ Configure vs Customize vs Custom Module vs Integration
This decision tree is the single tool used throughout the rest of the series whenever a hospital or real estate requirement needs to be evaluated. Every requirement in Parts 2 and 3 is run through it before deciding how to implement it:
π§π© The Bangladesh Business Context
Currency. Both companies operate in BDT (৳) β every illustrative amount in this series is shown in Taka, and Currency/exchange-rate configuration should be set up per company accordingly.
Fiscal year. Bangladesh's government fiscal year commonly runs JulyβJune. This is a general convention, not a guarantee β the specific fiscal year configured in ERPNext for a given company must be confirmed, since a private company's accounting fiscal year can differ from the national government fiscal year.
Addressing. Realistic Address records for both companies should follow Bangladesh's District/Division-based structure β e.g. Dhaka District, Dhaka Division β rather than a generic city/state/zip layout, since that's the address shape staff and customers actually expect to see and search by.
Local banking and mobile financial services. bKash, Nagad, and Rocket are payment channels commonly used in Bangladesh for customer and vendor payments. Any specific integration with one of these providers must be verified against that provider's current API and whatever connector, if any, is actually available or supported for the target ERPNext/Frappe version β this series does not claim a specific built-in ERPNext integration exists for any of them.
Customer types. Corporate, government, and individual customers are modeled through ERPNext's existing Customer Type and Customer Group configuration β not through new DocTypes. A government hospital contract and an individual walk-in patient's guardian are both just differently-configured Customer records.
β‘οΈ What's Next
With the methodology, environment discipline, and decision framework established, the next two parts apply this exact approach to each company in turn:
| Part | Focus |
|---|---|
| 2 | Bangladesh Hospital Management β Dhaka Care Medical & Hospital Ltd.'s full ERPNext implementation, department by department |
| 3 | Bangladesh Real Estate & Construction β Dhaka Skyline Properties & Construction Ltd.'s full ERPNext implementation, from land acquisition to installment collection |
| 4 | Custom Development, DevOps & Production β the technical/DevOps layer underneath both companies' custom apps |
For the general Frappe/ERPNext architecture, installation, and accuracy conventions this series assumes throughout, see the ERPNext Beginner to Intermediate course, particularly its architecture and installation sections. For permissions in depth, see Role Permission Manager vs User Permission Manager. For the accounting theory underneath every invoice and payment referenced in this series, see Invoice vs Payment: The Complete ERP Accounting Architecture and the Accounting to ERP curriculum.