Bug #2843
Station Expense Ledger Report - UI implementation
Description
Cursor Implementation Summary – Station Expense Ledger Report
Objective
Implement a Station Expense Ledger Report where Station is the primary reporting entity. The report should provide a complete financial view of all expenses incurred for a station across Operations, Site Development, and Maintenance, with a ledger-wise breakdown. The design follows common accounting practices where expenses are posted to ledger accounts and analyzed by cost center/project.
Business Requirement
Provide a report that answers the following questions:
How much expense was incurred for a station?
Which Classification generated the expense?
Which Ledger (Expense Head) was used?
Which employee incurred the expense?
How much advance was received?
How much expense was claimed?
How much expense was approved?
What amount is still pending?
What is the total expense for the station?
Important
Expense Approval applies only to expense claims.
Cash Advance approval is NOT part of this report.
Advance Received is shown only as a reference amount.
Report Hierarchy
Station
├── Classification
│ ├── Ledger
│ │ ├── Employee
│ │ │ ├── Expense Entries
Example:
Station Jaipur DC-01
Operations
Electricity
Rahul
₹5,200
Amit
₹3,500Travel
Rahul
₹1,800Maintenance
Machine Repair
Mohit
₹15,000
Site Development
Civil Work
Kunal
₹85,000
Filters
Station
Station
Station Code
Classification
Operations
Site Development
Maintenance
Ledger
(All Expense Heads)
Employee
Employee
Employee ID
Status
Draft
Submitted
Approved
Rejected
Hold
Paid
Date
Expense Date
Claim Date
Date Range
Amount Range
Report Columns
Station Information
Station Name
Station Code
Classification
Ledger
Ledger Name
Ledger Code
Employee
Employee Name
Expense Details
Expense Date
Voucher Number
Expense Description
Financial Details
Advance Received
Claimed Amount
Approved Expense Amount
Paid Amount
Pending Amount
Balance
Summary Cards
Display:
Total Station Expense
Total Claimed
Total Approved
Total Paid
Total Pending
Total Advance Received
Grouping
Support grouping by:
Station
Classification
Ledger
Employee
Month
Drill Down
Station
→ Classification
→ Ledger→ Employee→ Individual Expense
Export
Excel
CSV
PDF
Backend Requirements
Create a new reporting API with server-side filtering and pagination.
Support aggregation by Station → Classification → Ledger → Employee.
Calculate summary totals dynamically based on filters.
Optimize queries for large datasets using indexed fields (Station, Classification, Ledger, Employee, Expense Date, Status).
Ensure ledger names are sourced from the master ledger configuration for consistency and auditability. Expense reporting should retain clear links between expense lines, users, and ledger postings.
Acceptance Criteria
Station is the primary reporting entity.
Expenses are grouped by Classification → Ledger → Employee.
Ledger-wise totals are displayed for every station.
Advance Received is displayed separately and is not treated as an approved expense.
Approved Amount includes only approved expense claims.
Users can filter by Station, Classification, Ledger, Employee, Status, Date Range, and Amount.
Users can drill down from Station → Classification → Ledger → Employee → Individual Expense.
Summary totals update dynamically based on filters.
Reports support export to Excel, CSV, and PDF.
The report performs efficiently for large datasets using server-side filtering and pagination.Updated by Yashaditya Singh about 2 months ago
I implemented the Station Expense Ledger Report, ensuring full alignment with our project’s design system. I developed the main UI, integrated API services with custom apiClient for authentication, and enabled hierarchical drill-down functionality (Station → Classification → Ledger → Employee).
Updated by Shreya Agarwal about 2 months ago
Analyzed and mapped relationships across 7 database tables (charging_stations, expense claims, advances, accounting vouchers, ledgers, classifications, and users). Identified the expense workflow where claims are linked to stations and classified as Operations, Maintenance, or Site Development with proper OPEX/CAPEX treatment.
worked on fixing the drill-down API issue where the employee level was throwing a database error . The root cause was that the adv (employee_advances) table alias was being referenced in the GROUP BY clause even when the table didn't exist in the database schema. . This change was applied to both BuildStationGroup and BuildEmployeeGroup methods. The fix ensures that the employee drill-down works correctly without affecting other grouping levels like expense, classification, ledger, or month, and maintains backward compatibility with existing functionality.
testing is pending .Updated by Shreya Agarwal about 2 months ago
continued solving the employee level drill-down issue where the API throws error 42P01: missing FROM-clause entry for table "adv". I analyzed the code flow and found that the adv table alias is being referenced in the SQL query without the proper JOIN condition when grouping by employee. I made changes to make the GROUP BY clause conditional in BuildEmployeeGroup and BuildStationGroup methods, and also added parameter checks for FromDate and ToDate in GetGroupedAsync method. Despite these fixes, the error persists. I need to trace the complete SQL query being executed to identify the exact location where adv is being referenced without proper JOIN.
Also learning react concept like router and props which help me in my work
Updated by Yashaditya Singh about 2 months ago
I focused on testing the Station Expense Ledger module to verify the accuracy of data retrieval, filters, grouping, pagination, export, and overall report behavior. Alongside testing, I implemented the drill-down functionality, enabling users to navigate from summary-level data to detailed expense records while preserving the applied filters and report context. I also validated the drill-down flow to ensure correct data is displayed at each level and addressed issues identified during testing to improve the overall functionality and user experience.