📁 File 1 of 4

🏦 NBFC Loan Management System

Module: System Setup & Administration — Organizational Hierarchy, User Roles & Permissions

🏢 Head Office 🗺️ Regional Office 🏪 Branch 👤 User Role 🔐 Permissions 👥 User Creation ✅ Maker-Checker Config 📅 Financial Year
ℹ️
Developer Note: Fields marked with * are MANDATORY and must be validated on both frontend (HTML5 required) and backend. All forms should follow Maker-Checker workflow — Maker submits → Checker approves before data is saved to DB. Audit log entry must be created for every Add/Edit/Delete action.
🏢

Form 1: Head Office (HO) Creation

Admin → Organizational Setup → Head Office | Used by: HO Admin Only
🔧 Developer Note: This is the top-most entity in the hierarchy. Only ONE Head Office exists per LMS instance typically. HO ID is the parent for all Regional/Branch data. This form should be accessible only to Super Admin / HO Admin. Add HO_ID as a FK in all downstream tables (Regional, Branch, etc.).
📌 Used in: Reports headers, letterheads, all system-generated documents
📌 Used in: Auto-generating Branch Codes, Account Numbers, Voucher IDs
📌 Used in: Invoices, GST reports, compliance documents
📌 Used in: RBI compliance reports (NBS-1, NBS-2), audit documents
📌 Used in: Loan Agreement footers, RBI submissions
📌 Used in: TDS computation, income tax filings
📌 Used in: NOC letters, loan agreements, regulatory filings
📌 Used in: Address on official documents
📌 Used in: GST state code, regional mapping
📌 Used in: Address validation, geo-mapping
📌 Used in: SMS gateway config, official communication
📌 Used in: Email alerts, scheduled MIS reports, notifications
📌 Optional – Used in: Loan Agreement footer
📌 Used in: All printed reports, certificates, loan documents
📌 Used in: Company profile reports, audit documents
🗺️

Form 2: Regional / Zonal Office Creation

Admin → Organizational Setup → Regional Office | Used by: HO Admin | Reporting to HO
🔧 Developer Note: Regional Office is optional as per doc. If not required, a DEFAULT Regional record must be auto-created at time of HO setup. Regional ID is FK in Branch table. Regional_code prefix will be used in Branch code generation. Table: tbl_regional_office
📌 Used in: Branch hierarchy display, regional MIS reports
📌 Used in: Auto-generating Branch codes (NZ01BR001)
📌 Links Region to HO; FK: HO_ID
📌 Used in: Regional reports, escalation matrix
📌 Used in: Regional reports header
📌 Used in: Escalation notifications
📌 Used in: MIS email delivery
📌 Inactive region: no new branches can be created under it
🏪

Form 3: Branch Office Creation

Admin → Organizational Setup → Branch | Used by: HO Admin / Regional Manager
🔧 Developer Note: Branch is the primary operational unit. All Loans, Customers, Accounts are linked to a Branch. Branch users can access ONLY their branch data. HO users have global access. Branch Code auto-generation: [HO_CODE]+[REGION_CODE]+[SEQ]. Table: tbl_branch. FK in: tbl_member, tbl_loan_account, tbl_transactions.
📌 Used in: Branch-level reports, user login identification
📌 Used in: Loan Account Numbers, Voucher Numbers, Receipt Numbers
📌 FK: Regional_ID — defines hierarchy and reporting chain
📌 Used in: Bank transfers, NACH mandate setup, payment processing
📌 Used in: Approval workflows, escalation matrix
📌 Used in: Financial year opening, initial balance entry
📌 Used in: Day-closing cash verification, alerts when cash exceeds limit
📌 Used in: Opening GL entry, Day Book starting balance
📌 Used in: Official letters, loan documents
📌 Used in: District-level MIS reports
📌 Used in: State-wise portfolio reports
📌 Used in: SMS alerts, customer communication
📌 Used in: Scheduled MIS email delivery to branch
👤

Form 4: User Role Creation

Admin → Role Management | Used by: HO Admin Only
🔧 Developer Note: Roles are templates — when a User is created under a Role, all permissions from that Role's template are auto-applied. Roles define Approval Levels (e.g., Branch Manager = Level 2, HO Credit = Level 3). Role ID is FK in User table. Black/White maintenance is also tied to Role — only specific roles can see "Black" data.
📌 Used in: User assignment, approval-level matrix, access control
📌 Default permission template applied based on this type
📌 Used in: Loan approval workflow, maker-checker enforcement
📌 Transactions above this amount require higher-level approval
📌 Black = hidden/special financial entries visible only to authorized roles
📌 Internal documentation for developers and administrators
📋 Reference: Default Role Templates

🔹 Loan Officer

  • ✅ Add Loan Application
  • ✅ Edit Customer
  • ❌ Approve Loan
  • ❌ Delete Customer
  • ❌ Reverse Receipt

🔸 Branch Manager

  • ✅ Approve Loan
  • ✅ Reverse Receipt
  • ✅ View All Branch Reports
  • ✅ Day Closing
  • ❌ Create Loan Product

🔺 HO Admin

  • ✅ Create Loan Product
  • ✅ Approve High Value Loan
  • ✅ Global Reports
  • ✅ System Config
  • ✅ All Modules
🔐

Form 5: Permission Matrix

Admin → Permissions | Map Module Rights to Roles | Used by: HO Admin Only
🔧 Developer Note: Store permissions in tbl_role_permissions table with columns: Role_ID, Module_ID, can_view, can_add, can_edit, can_delete, can_approve, can_export. Load this table at login and cache in session. Every API endpoint must validate these flags before processing. Buttons on UI should be shown/hidden based on this matrix.
Module Name 👁️ View ➕ Add ✏️ Edit 🗑️ Delete ✅ Approve 📤 Export
Customer Onboarding
KYC Management
Loan Application
Loan Approval
Disbursement
EMI Collection
Receipt Management
Overdue / NPA
Accounting / GL
Reports & MIS
Loan Scheme Config
Loan Closure
Audit Trail
System Utilities
Gold Loan – Ornament
MFI / Group Lending
👥

Form 6: User Creation & Branch Mapping

Admin → User Management | Used by: HO Admin / Branch Manager (for branch-level users)
🔧 Developer Note: When User is created, auto-apply Role's permission template. User must be mapped to a Branch — this restricts their data access. HO Admin is not branch-restricted. Store hashed passwords only (bcrypt/argon2). Session must contain: User_ID, Branch_ID, Role_ID, Approval_Level, Permissions_JSON. Table: tbl_users.
📌 Used in: Audit logs, maker-checker records, report signatures
📌 Used in: Salary management, HR module integration
📌 Primary login identifier — must be unique across system
📌 Store only hashed (bcrypt). Force change on first login.
📌 Auto-applies permission template for this role
📌 User will ONLY see data of this branch
📌 Used in: OTP authentication, SMS alerts for approvals
📌 Used in: Password reset, scheduled reports delivery
📌 Used in: Salary module, employee reports
📌 Inactive/Suspended users cannot login; existing data remains
✅

Form 7: Maker-Checker Configuration

Admin → System Config → Maker-Checker | Used by: HO Admin Only
🔧 Developer Note: Maker-Checker is configurable per Transaction Type. Store config in tbl_maker_checker_config. When M-C is enabled for a transaction: Maker submits → record saved with status=PENDING → Checker reviews → on Approve, status=APPROVED and actual DB/GL update happens. On Reject, status=REJECTED. All states must be saved in audit log.
Transaction Type Maker-Checker Required? Min Amount for Approval (₹) Checker Role Level
Loan Application Submission
Loan Disbursement
Receipt / EMI Collection
Manual Journal Entry
Receipt Reversal
Loan Closure / Foreclosure
📅

Form 8: Financial Year Setup & Control

Admin → Financial Year | Impacts all: Accounting, Reports, Period Locking
🔧 Developer Note: Financial Year is the backbone of all accounting. All GL entries, trial balance, P&L, balance sheet are Financial Year-scoped. Only ONE FY can be ACTIVE at a time. When FY is changed, carry-forward balances are auto-created (Opening Balance entries). Closed FY periods must be locked to prevent modification. Table: tbl_financial_year, tbl_period_lock.
📌 Displayed in all reports, GL entries
📌 Typically April 1 for Indian companies. All transactions from this date
📌 Typically March 31. Transactions after this date go to next FY
📌 Only Active FY allows new transactions
📌 After freeze: No edit/delete allowed, only view. Prevents data tampering.
📌 Used when schemes have "Interest on Tenure End" — provisions are made periodically
📁 File 1 of 4 — NBFC LMS Documentation Forms  |  ➡️ Continue to File 2: Customer Onboarding & Loan Application Forms

All forms follow Maker-Checker workflow unless configured otherwise • Mandatory fields marked with * • Audit log required for every transaction