Oorja App Auto Bill Validation & Payment System PDF

OORJA APP INTRODUCTION This app is for BSNL officers to verify the Electricity Bills issued by State electricity Boards/Discoms to BSNL Offices, Exchange Building, BTS site etc. It is Auto Bill Validation & Payment System: The payment process in oorja app will be automated and will need minimum manu...

OORJA APP INTRODUCTION This app is for BSNL officers to verify the Electricity Bills issued by State electricity Boards/Discoms to BSNL Offices, Exchange Building, BTS site etc. It is Auto Bill Validation & Payment System: The payment process in oorja app will be automated and will need minimum manual intervention unless any discrepancy in bill is noticed or in case due to lack of data, validation is not feasible. The acquisition of data from DISCOMs shall be automated and will be populated in Oorja on regular basis. The bills raised by DISCOM shall be captured on daily basis by bill aggregator and will be provided to Oorja Application (By ITPC) through FTP server. The Oorja application will validate each bill based on automated validation algorithms. Steps of Auto Bill Validation & Payment System: S1 Bill fetch from Vendor: Fetch bills from Discom Web Portal & convert PDF into xls format. Vendor is going to fetch bills from respective Discom web portals and converts bill PDF into xls format in a predefined Discom specific template (provided by BSNL) on daily basis. Both bill PDF & xls format of bills will be provided to ITPC through FTP on daily basis. S2- Auto Bill Validation Following 3 processes are involved in Auto Bill Validation: I Sanity Bill Validation (SBV)  Check for Meter faulty through OMR & CMR.  Check for Consumed Units – 0 & Avg. Billing cases.  Check for Number of Units Consumed + OMR = CMR. 1  Check for Meter Continuity by tallying OMR of the Present Month with CMR of the Previous Month.  Exceptions in any one of the above checks will be treated as failed in Sanity Bill Validation.  The SBV failed Invoice/Bills will be sent to Site in-charge for his approval & remarks.  Sanity Failed Invoices will not be validated for next DBV & OBV validations due to lack of info.  The Sanity Bill Validation success Invoices will be sent for Discom & Oorja Bill Validations.  Sanity Bill Validation failed Bills will be identified as starting letter “S” in the “Bill Id”. II Discom Bill Validation (DBV)  The Bills will be Validated based on historical data i.e. Average of last 6 months Consumed Units & Current Amount Pay and calculate Relative Percentage Variation w.r.t. Present month Consumed Units & Current Amount Pay.  If Invoice having any one of the above Relative Percentage Variation < -30% or > 10% will be treated as Discom Bill Validation failed.  If both the Relative Percentage Variations within -30 to +10% treated as Discom Bill Validation (DBV) is Success.  Irrespective of the Discom Bill Validation failed/Success, all the Discom Bill Validation Invoices will be sent for Oorja Bill Validation.  Discom Bill Validation failed/Success Bills will be identified as starting letter „D‟ in the “Bill Id”. III Oorja Bill Validation (OBV)  Oorja Bill Validation is just like normal bill tariff validation in Oorja App with auto filling of all  Permanent (A), Dynamic (B) and Calculated(C) parameters and calculates the Percentage Variation.  If all the Dynamic Parameters are available in the Bill Data provided by Bill Fetch Vendor & Bill  Category configured in the Oorja then those Invoices will be taken for Oorja Bill Validation. 2  Failing the above scenario – Invoices cannot be processed for Oorja Bill Validation and end up with exclusive Discom Bill Validation.  If Percentage Variation of Oorja Calculated Gross Amount w.r.t. Discom Gross Amount is < +/-5% treated as OBV Success. If it is exceeds +/-5% then these bills will be treated as OBV failed.  If the Invoices having both OBV & DBV success then these cases will be sent directly to DGM (F) for financial approval then sent to Circle Nodal for final approval.  If Invoices having any one of the Validation – DBV or OBV fails then these cases will be sent to Site In-charge for his approval with remarks.  A docket will be generated against the bill when any one of the SBV/DBV/OBV Validation fails.  All the Oorja Bill Validation (failed/Success) Bills will be Identified as starting letter „U‟ in the “Bill Id”.  If all 3 validations are success then those bills will be identified as starting letter „A‟ in the Bill Id. S3-Bill approval Based on thresholds, Bills has to approve by Site Inch. / DGM (F)/ Circle Nodal.  After scrutiny of exceptions raised, site in-charge has to approve the bills.  Bills which are directly received from system have to approve by DGM (F) through bulk approval.  Circle Nodal @ L1 has to approve all the bills which are approved by Site In-charge and DGM (F) through bulk approval.  All the approved bills are progressed to ERP for generation of liability. S4-ERP Integration for Liability Generation: Liability will be generated for the bills through ERP Meter Master & Vendor Master  Circle designated AO has to run a T-Code in ERP-SAP to generate a liability document no. against  each Invoice. If prime data – BA, CAN, Meter No, Cost Center No., Vendor Code and Partner Bank type are tallied for the received invoice, a liability document number will be generated and updated back to Oorja. 3  Any mismatch on above will lead to ERP failure – IF/LF bills will be pushed back to L1 for resolution. S5 – Pay Priority Based on Fund Avbl & Pay Priority, Payment request initiated by Circle Nodal.  All the liability generated bills will be pushed back to Circle Nodal @L2. CN has to a send requisition to CSC for fund allocation against liability.  Pay Priority Module designed based on the priority algorithm with the predefined Payment categories – Gold/Silver/Bronze/Z. and Allocated fund.  Based on fund allocation, Circle Nodal @ L2 has to run the Pay Priority Module to generate a prioritized list of Invoices and initiate a Payment Request through CSC/Payment Aggregator. S6- Payment through CSC/Payment Aggregator: Bill Payment will be done by CSC / Payment Aggregator & Ack.  There are two modes of Payment of EB Bills – CSC and Payment Aggregator (SBI – under development)  Invoices which are having Virtual Bank Account Numbers against each CAN, has to use the CSC mode of Payment.  Invoice which is not having Virtual Bank Account numbers has to select the Payment Aggregator mode of Payment.  In case of CSC, acknowledgement will be updated back to Oorja.  In case of PA – acknowledgement will be updated to ERP through Oorja. 4 Oorja Auto Bill Validation & Payment Work flow V1.0: 5 Oorja Auto Bill Validation & Payment Work flow V2.0 : 6 Unprocessed Bills – Role of Circle Wkg. Node: After ABV process if bills are having Meter Mismatch or MSA form not approved by SI or both constituted as unprocessed bills: The Invoice/Bill data will be checked for Meter No. as per SSA verified template data (ECAV) If it is not matched these Invoices are flagged with MM (Meter Mismatch). Check for Site previous month current readings certified by Site In-charge through Monthly Site Approval form (MSA). If site in-charge not approved then these Invoices are flagged with MSA. MM & MSA – bills are treated as unprocessed bills and will not be allowed to push directly to Site In-charge/DGMF. Will be appeared under Unprocessed Bill box. These Unprocessed bills will be pushed to Circle Wkg. Node Inbox for verification and will be released to Site In-charge after necessary changes. For MM cases, Meter No has to be updated with New in ECAV MM & ERP Meter Master. If Due Date is near, there is an option to Continue with existing Meter Number without change of New Meter Number. Before next billing Cycle the entire Meter No. mismatches has to be updated in both MM Oorja & ERP otherwise these bills will not be allowed for further processing. New Meter number can be updated through Oorja ECAV MM form. A- Param will be updated auto.MSA cases can be released to Site In-charge if consent received from Site In-charge otherwise these bills can be cancelled. Role of Site In-charge (SI): All Sanity, Discom & Oorja Bill Validation failed Invoices will appear under “Bills Pending at Site In-charge “ block in Auto Bill Validation & Payment Dashboard. Site In-charge can verify the reasons for SBV, DBV & OBV failed cases through Bill Summary. Can verify the last 6 months Consumed Units & Current Amount data for Relative Bill % Variation. Can verify the Oorja - A, B & C Parameters in comparison with Discom Parameters in case of Oorja Bill Validation. Invoice mile stones can be viewed through Work Flow (WF) button. Bill PDF issued by Discom Web Portal can be viewed through „BILL‟ button against each 7 Invoice. Site In-charge can also have facility to see all the stages of Invoices in all the blocks of dashboard. All the approved Invoices will be sent to DGM (F) for Financial Approval. The dockets will be auto generated based on exceptions in SBV/DBV/OBV. The docket can be closed by identifying the reasons for variations in Oorja calculated values w.r.t. Discom Parameters values and escalate to Oorja or escalate the issue to Discom with proper reasons and remarks. Invoices cannot be processed for payment in the next month if it has a pending Docket. Validation & Alert Check list for Site In-charge before approving the Payment: SBV, DBV & OBV: Exception in these 3 Validations if any will be shown for verification. Alerts: The following Alerts/Warnings due to abnormal variations in the vital parameters are given to SI for verification and approve the bill accordingly:  MM & MSA: Meter Mismatch & MSA not approved cases released by CWN for verification.  MSA_W: If Current Meter reading is not in between the Discom CMR & OMR.  FAA_W: If Final Approved Amount is beyond1 lakh rupees.  CU_W: If Consumed Units (CU) > 100% of Relative % Variation w.r.t last 6 months avg. of CU.  CA_W: If Current Amount Pay (CA) > 100% of Relative % Variation w.r.t last 6 months avg. of CA.  SC_W: If Late Payment Surcharge > 30% of Current Amount Pay may due to unpaid disputed bill.  MI_W: If Discom issues more than one Invoice against a site within 25 days will be identified as Site having Multiple Invoices (MI_W) within the billing cycle may be due to Revised or Duplicate Bill. Multiple Invoice details are given for approving the correct bill and reject the wrong bill. If Invoice having any predefined alerts/warning then the Invoice will be routed to SI though all 3 validations are success. Site In-charge has to verify these alerts (if any) before approving the bills. Based on 3 validations – SBV, DBV & OBV and 8 Alert/Warnings against Invoice Site In-charge has to take appropriate decision whether to approve the bill with protest or can raise a complaint to the Discom for Revised bill. Site In-charge has to approve the Invoice by submitting the appropriate reasons with remarks under “Bill Approval” tab through APPROVE button against each Invoice. If a Site In-charge doesn't want to Pay the bill due to site closed/abnormal bill as mentioned in Alerts/etc. can select the option “Not to Pay” and submit the “NOT TO PAY” button with proper remarks. These bills will be moved to “Unapproved/Rejected Bills” tab. Role of DGM (F): Invoices which are approved by Site In-charge and Invoices which are validated by Oorja System (DBV & OBV Success) will appear in “Bills Pending at DGM (F)” block in the dashboard. Need to verify the Final Approved Amount, Tax components etc. derived from Bill is correct or not. Any discrepancies need to escalate to ITPC through Circle Nodal for implementation. DGM (F) has to approve the entire Invoice by pressing “Bulk Approve” button through Select All, Multi Select or can also approve Individual Invoices like Site In-charge. DGM (F) can send the Invoice back to Site In-charge if any discrepancies in the Invoice. All the approved Invoices will be sent to Circle Nodal for final Approval. Role of Circle Nodal @ L1 Stage: Invoices approved by DGM (F) will appear under “Circle Nodal (L1) “block in the dashboard. Circle Nodal has to approve all the Invoice by pressing “Bulk Approve” button through Select All, Multi Select or can also approve Individual Invoices like Site In-charge. Circle Nodal can have all the feature of Site In-charge. Circle Node can send the Invoice back to DGM (F)/Site In-charge if any discrepancies in the Invoice. All the approved Invoices will be sent to ERP for Liability generation. If the Invoice having Final Approved Amount is „0‟ then these cases will directly sent to „Bills Paid‟ block. Invoice Failure (IF): If CAN/MeterNo/VAN/PBT/Cost Center numbers with ERP MM any mismatch in then the Invoice will be failed and returned back to L1. These are identified as ERP Status: Y-IF. Liability Failed (LF): If Invoice returned after generation of Liability due to any issue, these Invoices will be returned back to L1 with ERP Status as: LF. Multiple Invoice 9 (MI): If Discom issues more than one Invoice against a site within 15 days (duplicate bill or revised bill) will be identified as MI. Need to verify and approve the correct Invoice manually. After resolving the mismatches or any other issues, IF/LF Invoices can be re-submitted. Has to monitor the Dockets and see that all the pending dockets will be closed through BA Nodes/ Circle Working Nodes before the next billing cycle. Invoice Failure – IF Invoices Failure error occurs after running T-Code at ERP for liability generation when any mismatch or mandatory parameter missing in the ERP Meter Master or Vendor Master. Reason for Invoice Failure updated in Work Flow of that Invoice. The following Invoice Failure Remarks and Reasons. 1. No Cost Centre found: This is due to mismatch of BA Code/Meter No. /Vendor Code/Cost Centre Number/Virtual Account Number/Partner Bank Type info in ERP Meter Master/Vendor. This error has to be resolved by Circle with the help of FICO team 2. GST No or PAN not available: This is due to GST or PAN not available in Vendor Master. This error has to be resolved by Circle with the help of FICO team. 3. Vendor Code not defined: This is due to wrong/missing Vendor Code in ECAV. Need to update in ECAV meter master with correct Vendor code and need to inform to ITPC for reprocessing. 4. XXXX is already posted by document number: This is due to the Invoice liability already generated in ERP with same Invoice Number. Need to be verified with Invoice number in ERP. If Discom issuing same Invoice Number to more than one Bill, need to be informed to ITPC for processing dummy Invoice number. 10 IF cases resolved by ITPC a. FI/CO interface: Balance in transaction: This is due to amount mismatch in Non Taxable charges, Taxable charges and Arrears. This error will be resolved by ITPC. b. IGST/CGST Amount Does not match: This is due to wrong computation of SGST/CGST values by Discom. This c. error will be resolved by ITPC. Amount is Negative: This is due to wrong computation of Non Taxable Electrical Charges, AdjDebit, AdjCredit and Invoice Amount. This error will be resolved by ITPC. d. Incorrect Invoice Number: This is due to spaces between Invoice/Bill Number or above 16 digits. e. This error will be resolved by ITPC. f. Key data missing: This is due to missing of important parameters. This error will be resolved by ITPC. Liability Failure – LF: 1. If circle wants to cancel the already generated liability and not yet paid Invoices due any reason, a T-Code has to run to cancel the liability. These Invoices liability will be cancelled and return to L1 inbox with a tag called LF – Liability Failed. 2. These LF Invoices can be cancelled permanently by Not Approving with remarks. 3. These Invoices can be resent to ERP for regeneration of Liability after necessary modifications. Role of ERP: Liability will be generated for the Invoices (approved by Circle Nodal (@L1)) based on the following: Matching of BA, CAN, Meter Number & Vendor Code of Invoice w.r.t. ERP Meter Master. If any mismatch in these Parameters, Invoice will be failed to generate Liability. 11  ERP Parameters:  Meter Rent, SGST, CGST, IGST, UTGST and TCS amount will be captured from Invoice.  Non Taxable Electrical Charges = Current Amount – (Meter Rent + Taxes if any)  Invoice Amount = Current Amount + Meter Rent + Taxes (if any) + Surcharge + TCS  Adj. Debit & Adj. Credit = Arrears (+/-).  TDS will be calculated by ERP (Circle specific)  Net Payable to Vendor = Gross Amount – TDS.  Gross Amount (as per Discom) = Invoice Amount + Adj. Debit - Adj. Credit.  Liability will be generated for the “Net Payable to Vendor” amount only and this is the final amount which is going to pay to Discom.  As per Oorja - Final Approved Amount = Gross Amount – Arrears. Hence the Net Payable to Vendor = Final Approved Amount – TDS. Note: If at all any issue in the formula, kindly escalate to ITPC for customization. Role of Circle Nodal @ L2 Stage: After generation of Liability Document Nos. by ERP, all the Invoices will be sent back to Oorja. These Invoices will be appeared under “Pending Bills at Circle Nodal (L2) “tab in the dashboard. A separate dashboard is there for Pay Priority Management through “Bulk Approve” button in the “Pending Bills at Circle Nodal (L2)” tab. Pay Priority Management works on the Pay Priority Algorithm issued by CO Electrical Wing. Pay Priority Approval can be done Circle or BA wise as per Fund Allocation against total liability. Circle Nodal has to post the Circle/BA wise allotted Amount in the “Total Fund Allotted” and has to execute the “Generate Pay Priority” button. This will auto publish the two lists - One is on Right Section: “Selected Bills” will show the list of bills whose total amount within the Total Fund Allotted” and Second One is on Left Section: “Leftover Bills” will show the list of Bills whose total amount exceeds the Total Fund Allotted. Circle Nodal has a facility to modify this priority by unselect the bills on Right Section and can select the bills on Left Section. By doing this 12 bills can be moved from one section to other so that selective bills under Pay categories GOLD/SILVER/BRONZE/Z can only be sent for Payment. After Selection of bills on Right Section – Circle Nodal has to initiate the Payment Request through “Payment through CSC”/”Payment through Payment Aggregator” buttons. Work Flow (WF): 1. Work Flow (WF) button is available against each „Bill Id‟ throughout all the stages in the dashboard. 2. Work flow Menu shows the mile stones of the Invoice. 3. The following statuses are shown against each Invoice to know the Site Incharge/Circle Nodal Hrms. No. , Date of Approval, Role and his Remarks to know the exact status of the Invoice. 4. a. Bill approved by Site In-charge. b. Bill approved by DGM (F). c. Bill approved by Circle Nodal (L1). d. Invoice Read by ERP e. Liability Document Number posted by ERP. f. Payment Request Initiated by Circle Nodal (L2) g. Payment Request Read by ERP for Payment through CSC. h. Payment done by CSC Successful. Some more miles stones will be added after integration of Payment Aggregator. 13 Project OJAS The project OJAS is an initiative by BSNL in order to save energy and focus on tapping of renewable sources of energy. The project will help in optimizing the energy consumption and have a positive impact on global warming. The project starts from 7 Aug 2018. PROJECT OJAS- ROADMAP 1. Implementation of in-house software for analyzing and scheduling the electricity bills for identification and corrective action. 2. Analysis of existing tariff for adoption of economical tariff from existing utility co. or any other alternate source of supply if available & Exploring the possibility for single window payment. 3. Review of demand and taking corrective action for disconnection, contract demand rationalization, closure of substation, downsizing of DG set etc. 4. Closure of DG sets from urban/rural Exchanges/BTSs having reliable power supply and providing one mobile DG sets for a group of 20 sites in urban and 10 sites in rural. 5. Power plant optimization by clubbing of multiple power plants, removal of defective power modules, reduction in power plant capacity etc. 6. Non- provision of BTS at un-electrified sites and closure of non-electrified BTSs wherever feasible. 7. Implementation of Turbo Ventilator for BTSs cooling by replacing air conditioners. 8. Closure/removal of air conditioners provided to the non-entitled officers. 9. Provisioning of renewable energy resources on RESCO model from Renewable Energy Service Cos. (RESCOs) without CAPEX from BSNL. 10. On-line monitoring of above parameters at corporate level for implementation and corrective action by the circles. Methodology of project OJAS 1. SAVING in Energy cost by optimizing use of electricity. 2. Smart use of appliance 3. Temperature setting 14 4. Auto timer 5. Non parallel operation of transformer, 6. Non starting of DG immediately, 7. TOD optimisation (No Cost measure) 8. By using more energy efficient equipment like Turbo ventilator, LED and star rated equipment 9. By getting advantage of tariff by HT to LT 10. Changing the tariff slab 11. Minimizing the contract demand 12. Betterment of power factor 13. Conversion of commercial to industrial tariff 14. Electricity bill validation and rectification to benefit of BSNL Alternate energy source like solar, wind, hybrid 15