Bill Template Review

## Summary ### Issues with the Current Build System and the Concept of a Build Template The meeting centered on identifying and addressing fundamental flaws in the current legacy system's approach to handling "builds." The core problem is the absence of a properly utilized "build template," which is leading to multiple systemic issues. The current method is causing inaccuracies and inefficiencies in data capture and processing. - **Lack of Setup and Standardization**: The system lacks a mechanism to correctly set up builds within DSS (Data Submission System), which is a critical gap that needs to be addressed. - **Incorrect Logic Application**: Presently, specific logic (e.g., for determining observation types or usage charges) is being hard-coded or applied in an ad-hoc manner. This logic often already exists within the build template for a given account, so re-implementing it is redundant and error-prone. - **Inconsistent Data Entry**: In DSS, fields that should be constrained (like usage types) are currently freeform, leading to incorrect data entry and making it difficult for operators to correct errors. This creates a frustrating and inefficient audit experience. ### The Proposed Solution: Integrating the Build Template into DSS The primary solution discussed is to systematically incorporate the existing build template into the DSS workflow. This integration would act as a crucial safeguard, ensuring data integrity and streamlining operations by leveraging predefined rules. - **Template as a Single Source of Truth**: The build template, which is tied to a unique combination of customer, vendor, and account number, should dictate what data fields are applicable and what logic should be followed during data capture in DSS. This would eliminate guesswork and hard-coded rules. - **Cross-Platform Consistency**: While the immediate focus is DSS, the build template is envisioned as a shared resource that should be consistent across DDS, DSS, and UVM systems to maintain data coherence throughout the platform. - **Future-Proofing for Setup Builds**: Incorporating the template is also a preparatory step for a future where setup bills could be created directly within DSS, making the process more comprehensive and controlled. ### Determining Build Types: A Case Study in Flawed Logic A concrete example was examined to illustrate the problems with the current logic. The discussion focused on how the system determines a build's type (e.g., full service, distribution, or supply) and the downstream errors this causes. - **Current Flawed Methodology**: The system currently determines build type based on the service type listed on a bill, which can be incorrect or misleading, especially since a single bill can contain both distribution and supply components. - **The Correct Approach**: The build type should be definitively known and defined within the account's build template from the initial setup. Relying on the template would prevent misclassification. - **Example - Natural Gas Charges**: The logic that "wellhead use" is always applied for natural gas is incorrect. This should only apply if the build template specifies a *supply* or *distribution* type. Using the template would automatically enforce this correct rule. ### Addressing the DSS Audit Queue and Data Routing The conversation shifted to immediate, tactical issues regarding bills stuck in the DSS audit queue and how to route them for resolution effectively. - **Clearing the Audit Backlog**: There is a need to manually push invoices currently stuck in the DSS audit status over to the Data Audit system for operator review, similar to a process executed the previous week. - **Including Critical Error Context**: When routing these items to Data Audit, it is essential to include the specific error message or observation details in the operator notes field. This provides crucial context for the audit team to understand and fix the issue quickly, as this error information is not currently being passed through automatically. - **Scripting the Solution**: A script will be adjusted to facilitate this data move. While a more permanent, automated integration is the ideal long-term solution, the immediate fix involves updating the script to include the error details in the transfer. ### Next Steps and Implementation Planning The meeting concluded with a plan for executing the discussed strategies, balancing immediate fixes with longer-term architectural improvements. - **Immediate Action on Audits**: The first action is to run a script to transfer DSS audit items to Data Audit, ensuring all relevant error information is included in the operator notes for effective resolution. - **Investigating Template Integration**: Following the audit cleanup, the next major task is to investigate how to pull the build template data from DDS and integrate it as a safeguard within the DSS data capture process. This requires understanding the technical access and methods for retrieving this template information. - **Preparatory Work for Reporting**: Work will begin on creating a report template. Once the template is designed, the development team can proceed with its implementation to improve visibility and tracking.