Validation Rules Alignment

## Meeting Context and Objectives The meeting focused on resolving confusion around bill validation rules, specifically addressing the concept of "muting" non-critical errors to streamline payment processing. Key goals included clarifying terminology, aligning on business priorities, and confirming current system behavior to prevent miscommunication within the team. ### Background and Urgency - **Immediate operational pressure**: Significant bill payment delays and reconciliation issues for prepay customers were reported, with AP file inaccuracies causing month-end reconciliation failures. - **Terminology confusion**: The term "muting" lacked a shared definition-debated whether it meant disabling validations entirely or auto-resolving errors while retaining audit trails. ## Business Priority Alignment - **Critical focus areas**: Bill payments (ensuring timely payments to avoid utility shutoffs) and AP file accuracy (for accounting integration with platforms like Oracle) were identified as top priorities. - **Impact assessment**: While 95% of bill payments function despite validation errors, over 70% of AP files for prepay customers are currently affected by unresolved data discrepancies. ## Validation Rule Implementation - **Auto-resolution framework**: All validation errors except seven specific critical rules are automatically resolved by the system, eliminating manual intervention for non-blocking issues. - **Edge case handling**: Bills with multiple errors (including one of the seven critical errors) display legacy errors until reparsed, after which only critical errors persist. ### Critical vs. Non-Critical Rules - **Non-critical rules**: Primarily affect analytical data rather than payment/AP file functionality (e.g., meter serial number mismatches or service-day miscalculations). - **Critical rules**: Seven undisclosed validations remain active to prevent payment failures or AP file corruption, requiring manual resolution. ## Mock Bill Process - **Purpose and urgency**: Mock bills are created manually when physical utility bills are delayed, enabling on-time payments to avoid service disconnections during tight payment windows (e.g., 15-day deadlines). - **Validation parity**: Mock bills undergo identical validation checks as physical bills, occasionally triggering errors (e.g., virtual account mismatches) despite streamlined creation workflows. ## Technical Deep Dive: Error Resolution - **Days-of-service discrepancy**: A recurring error where billing period dates conflict with calculated service days. - **Root cause**: Systems inconsistently apply "end_date minus start_date" versus "end_date minus start_date plus 1" formulas. - **Solution proposal**: Enhance BSS/UVM integration to flag whether service days are provider-sourced or system-calculated. - **Observation codes**: Needed from DSS to resolve 2007/2008 errors, enabling automated fixes for line-item inaccuracies without bulk data operations. ## Communication and Next Steps - **Clarification directive**: The team will formally confirm that only seven validation rules remain active, with auto-resolution handling all other errors. - **Data dependency**: A list of DSS observation codes is required to address residual data inconsistencies affecting AP file reconciliation.