Bug #3097
Develop an API endpoint in `reporting-service` to extract all available fields from uploaded electricity bill PDFs
Description
Develop an API endpoint in `reporting-service` to extract all available fields from uploaded electricity bill PDFs and convert the extracted data into downloadable CSV format.
Header Button & Modal Trigger
Verify that a secondary "Import Bill (PDF)" button with an upload icon appears next to the "+ Add Bill" button at the top-right of the screen.
Clicking "Import Bill (PDF)" should open the "Import Electricity Bill" modal.
2. Dropdown & Cascading Verification
State Selection (State):
Default state should be Rajasthan.
Check selecting other states like Madhya Pradesh, Gujarat, Maharashtra, Delhi, Karnataka, Uttar Pradesh, etc.
Format / DISCOM Selection (discomFormat):
Verify cascading: Selecting Rajasthan should display JVVNL / AVVNL / JDVVNL (Standard Format).
Selecting Madhya Pradesh should cascade and update options to MPPKVVCL (West Zone), MPPoVVCL (East Zone), and MPMKVVCL (Central Zone).
Charging Station Selection (stationId) (Optional):
Dropdown should list all available Charging Station names (e.g. Amarpali Circle, Jammu Station).
Check that selecting a station links the imported bill to that station ID.
3. Billing Period Override (Month & Year)
Bill Month & Bill Year dropdowns should default to "Auto-detect from PDF".
Updated by Shreya Agarwal about 2 months ago
Today, successfully developed and verified the PDF Electricity Bill Parsing and Export feature for the reporting service. The primary objective was to build a robust, 100% dynamic parsing solution capable of extracting all electricity bill details from uploaded utility bill PDFs without hardcoding any static values.
The parsing engine processes the PDF stream and extracts 41 structured parameters, including consumer identity information, billing dates, reading periods, energy consumption units, itemized charge breakdowns, taxes, net payable amounts, late surcharges, and bank RTGS details. It includes normalization logic to clean Unicode non-breaking spaces, convert Hindi Devanagari numerals to standard digits, and transliterate Devanagari text into clean English text.
To support flexible data consumption, the API endpoint was equipped with dual-format export capability using a query parameter. When requested as JSON, the endpoint returns a structured response payload. When requested as CSV, it dynamically generates an RFC-4180 compliant spreadsheet file. All text fields, including complex addresses containing commas, are safely quote-escaped to ensure every value lands in its exact respective cell in Microsoft Excel or Google Sheets without misaligning columns.
The entire implementation was verified through Swagger UI testing, confirming 100% data extraction accuracy, flawless CSV downloads, and clean build compilation with zero errors.
Updated by Shreya Agarwal about 1 month ago
Backend : Today, implemented and modify as per requirement the Electricity Bill PDF Parsing, Auto-Station Mapping, and DB Persistence feature for the reporting-service. First, I created an idempotent database migration (V0181__add_k_number_to_charging_stations.sql) that adds the k_number column to charging_stations across all tenant schemas. The parser accurately extracts consumer info, meter readings, billing periods, due dates, and performs precise financial line-item aggregations (including energy charges, fixed charges, surcharges, TOD rebates, PF incentives, electricity duty, and cess) down to the exact paise while dynamically calculating the per-unit electricity rate.
Furthermore, I integrated automatic station lookup logic that resolves station_id from charging_stations by matching the extracted k_number. The service automatically updates or overwrites existing bill records for the same station and billing period (station_id, bill_year, bill_month), ensuring strict data consistency and preventing duplicate entries. Finally, I streamlined the API response in ElectricityBillController so that the /parse-pdf endpoint returns a single, clean response object (savedBill) directly inside the data field, eliminating duplicate nested wrappers .
Also in frontend : implemented the "Import Bill (PDF)" feature on the Electricity Bill Details Report screen . A secondary "Import Bill (PDF)" action button with an upload icon was added to the top-right header alongside the existing "+ Add Bill" button. Clicking this button opens the "Import Electricity Bill" Modal, which includes a State Selection dropdown, a cascading Format/DISCOM dropdown based on the selected state, a Charging Station dropdown displaying station names, an optional Billing Period (Month & Year) override section defaulting to "Auto-detect from PDF", and a drag-and-drop PDF file upload area. Upon uploading a PDF, the component connects to the POST /api/v1/reporting/reports/electricity-bill/parse-pdf?format=json multipart API to automatically parse and store bill details in the database.
Updated by Shreya Agarwal about 1 month ago
Enhanced the reporting-service (parse-pdf endpoint) to dynamically extract and auto-save Madhya Pradesh (MP) electricity bill PDFs into the database Supported both MP Discom PDF formats—Format 1 and Format 2 with 100% dynamic parsing and zero hardcoding, while keeping Rajasthan (JVVNL/AVVNL) bill parsing completely isolated and 100% regression-free.
Implementation & Fixes
Refactored ElectricityBillPdfParserService by isolating ParseRajasthanPdf and creating a dedicated ParseMpPdf method. Implemented dynamic RegEx patterns to extract K-Number, Bill Number, Meter Serial Number, Previous/Current Meter Readings, Consumed Units (units_kwh), Electricity Rate (energy_charge / units_kwh), Tax/GST, Due Date, and negative rebate breakdowns across both MP formats. Updated ElectricityBillService to automatically link charging stations by K-Number (charging_stations)
in fronntend : Date Format Refinement: Updated the Bill Start Date and Bill End Date display in the Electricity Bill Details view drawer to format as Month and Year (e.g., Jul 2026, Aug 2026) instead of standard numeric date strings.
Multi-State DISCOM Support & Validation:
Verified PDF parsing for both Rajasthan DISCOMs and Madhya Pradesh DISCOMs
Updated by Shreya Agarwal about 1 month ago
Today,implemented, integrated, and verified end-to-end support for Madhya Pradesh (MP) Electricity Bill PDF Parsing within the reporting-service while maintaining complete backward compatibility for Rajasthan DISCOM bills.
To support stations configured with multiple electricity meters, upgraded the station mapping and database persistence architecture. I updated the PostgreSQL station resolution query to search against PostgreSQL's string array column (character varying[]) enabling instant auto-mapping for any station with single or multiple K-Numbers. Additionally, refined the pre-insertion deletion logic in ElectricityBillRepository to filter strictly by station_id, k_number, bill_year, and bill_month. This key architectural enhancement ensures that uploading a new bill for a specific K-Number replaces only that K-Number's previous record upon re-upload, while allowing bills for different K-Numbers of the same charging station and billing period to coexist side-by-side as active rows
Furthermore, API response handling in ElectricityBillController was standardized to return an explicit HTTP 400 Bad Request (success: false) whenever an uploaded PDF contains a K-Number unlinked to any station in the database, eliminating false-positive success responses.
Updated by Shreya Agarwal about 1 month ago
continue workin on Electricity Bill PDF Parsing within the reporting-service while maintaining complete backward compatibility for haryana , mpRajasthan DISCOM bills.
today I worked both frontend and backend functionality to parsed and get data of pdf haryana bill , mp bill and rajasthan bill.
Furthermore, API response handling in ElectricityBillController was standardized to return an explicit HTTP 400 Bad Request (success: false) whenever an uploaded PDF contains a K-Number unlinked to any station in the database, eliminating false-positive success responses.
Updated by Shreya Agarwal about 1 month ago
Today, I stabilized and enhanced the multi-state electricity bill PDF parsing engine across Madhya Pradesh (MP Formats 1 & 2), Haryana (UHBVN/DHBVN), and Rajasthan (Unicode & KrutiDev legacy formats) with zero hardcoding. We first resolved a cross-page date order validation issue in multi-page MP Format 2 bills, ensuring start/end dates and billing periods are correctly ordered and saved without runtime errors.
Next, I fixed the Rajasthan parser classification and extraction logic. We resolved a routing misclassification where clean Hindi Unicode bills (e.g., Mandawar) were mistakenly sent to the KrutiDev parser due to shared discom GSTINs, ensuring proper separation between Unicode and legacy font formats. Additionally, I enhanced the KrutiDev parser regex to reliably extract 12-digit K-Numbers across both Ajmer (110...) and Jaipur (210...) discoms (resolving the "unknown K-Number" exception), supported AV.../JV... meter prefixes, and allowed 1-to-6 digit meter readings (such as 10.00).
Finally, performed end-to-end field-by-field verification against live database records across all bill types (Bills 170 through 187). All critical fields—including K-Numbers, meter numbers, readings, consumption units, energy charges, tariffs/rates, tax/cess breakups, and net payable amounts—achieved a 100% verified match with clean build stability.
Updated by Yashaditya Singh about 1 month ago
- Assignee changed from Shreya Agarwal to Yashaditya Singh
I worked on the electricity bill PDF parsing functionality and investigated the 400 validation error occurring during bill parsing. I reviewed the JVVNL Rajasthan bill format and identified that the uploaded PDF contains valid consumption data, including K Number, bill month, energy charges, current/previous KWH readings, and meter multiplier. I updated the parser approach to correctly identify the selected electricity provider and route the PDF to the appropriate provider-specific parser, with improved Rajasthan/KrutiDev extraction and unit calculation logic. The parsing flow was also adjusted so UnitsConsumed is calculated from the current and previous KWH readings with the meter multiplier, preventing the electricity-rate calculation from receiving zero units.