CalTABS_SOW_Attachment_1_-_Detailed_System_Requirements.xlsx
XLSX spreadsheet 62 KB Posted
- Attached to
- RFP 26-0214801 CalTABS
- Solicitation number
- 0000040138
- Issued by
- Sacramento County, Sacramento City, West Sacramento City, California
About this file
This is a detailed system requirements document for CalTABS Phase 1 Project, a modern Software-as-a-Service (SaaS) billing solution being procured by the California Department of Technology (CDT) to replace a legacy billing system. The RFP 26-0214801 seeks comprehensive implementation services and subscription licenses from qualified proposers to deliver end-to-end services including requirements analysis, system design, configuration of data ingestion and transformation processes from 30+ sources, system integrations, testing, training, pilot verification, go-live support, and system stabilization. The document outlines extensive functional requirements organized across multiple requirement categories including data collection and management, user experience, administrative roles and permissions, invoicing, reporting, mainframe integration, and security compliance. Key deliverables encompass a responsive web interface accessible across desktop and mobile devices, role-based access controls, CPU usage proration calculations, invoice generation workflows with approval staging, customizable reporting and dashboarding capabilities, and integration with the mainframe environment to process hundreds of millions of usage records monthly across multiple data sources including SMF records, storage metrics, and print job data.
The system requirements mandate mandatory compliance with NIST SP 800-53 revision 5 security standards, California State Cloud Computing Policy, and ADA accessibility regulations, with implementation of moderate security baselines. The system must operate in a cloud environment utilizing SaaS, IaaS, or PaaS service models and maintain 99.5% uptime availability with 24/7 operational readiness. Critical functional requirements include support for multiple CPU proration methods, configurable billing rate structures with effective dating, five-year data retention with queryable historical access, three parallel sandbox environments (Development, Test, Training) that mirror production functionality, and comprehensive audit logging of all user and system activities. The system must integrate with CDT's Active Directory for single sign-on, process scheduled and ad hoc data ingestion, maintain version control for all configurations, and support complex billing scenarios involving mainframe workload classification, specialty engine differentiation, DASD and tape storage billing, and hierarchical customer roll-ups with prevention of duplicate charges.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| CalTABS_SOW_Attachment_3_-_SLAs_FINAL.pdf | ||
| RFP_26-0214801_CalTABS_FINAL.pdf | ||
| CalTABS_SOW_Attachment_2_-_Deliverables_FINAL.pdf | ||
| Exhibit_B_-_Cost_Worksheet_FINAL.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| CalTABS Phase 1 Project Detailed System Requirements | |||||||||
| Mid-level | |||||||||
| Requirement Number | MLR Owner | Category | Sub-Category | Requirement Number | Requirement Description | Requirement Type (Functional or Non-Functional) | Priority | ||
| (Leave Blank for Now) | Requirement Owner | Priority | Comments/Context | ||||||
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.1 | The System shall calculate CPU usage allocations by applying a proportional formula based on each customer’s share of total system utilization within a defined period (e.g., daily, weekly, monthly). | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.2 | The System shall support multiple proration methods, including 1) Percentage of total CPU usage, 2) Time-sliced allocation (e.g., for partial-day or partial-job usage) 3) Weighted distribution based on configurable metrics (e.g., service tiers). | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.3 | The System shall ingest CPU usage data from mainframe performance reports (e.g., SMF, TMS, ADABAS Review tables). | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.4 | The System shall support raw usage collection at the Region/User/Transaction level. | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.5 | The System shall timestamp and tag each usage record with the reporting cycle. | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.6 | The System shall apply proration adjustments when 1) Shared resources are consumed by multiple customers simultaneously 2) Partial job runs occur due to failures, restarts, or truncation. | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.7 | The System shall round calculations using standard financial rounding rules (e.g., to four decimal places) to ensure billing consistency. | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.8 | The System shall allow State-level administrators to define the basis of proration (e.g., CPU seconds, MSU, MIPS). | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.9 | The System shall allow custom formulas to be applied, including caps, thresholds, or minimum charges. | Functional | RCR | Desirable | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.10 | The System shall validate CPU proration results against source totals to ensure reconciliation (e.g., 100% of CPU usage is allocated across customers). | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.11 | The System shall generate exception reports if usage data does not reconcile or if anomalies (e.g., negative usage, missing totals) are detected. | Functional | RCR | Mandatory | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.12 | The System shall provide rollback capabilities (e.g., recalculation of allocated CPU outputs for various reasons or selected periods) for recalculations if proration rules are updated. | Functional | RCR | Desirable | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.13 | The System shall provide detailed proration reports showing Raw CPU usage by source, Proration formula applied, Final allocated usage by customer/account code. | Functional | RCR | Desirable | |
| FD.01 | RCR | Data Collection/ Management | Data Management | 1.2.14 | The System shall feed prorated CPU usage outputs directly into the billing engine to calculate charges. | Functional | RCR | Mandatory | |
| FD.02 | RCR | Data Collection/ Management | Data Management | 1.2.15 | The System shall store or integrate with a secure centralized repository all raw billing and usage data collected from mainframe and non-mainframe sources. | Functional | RCR | Mandatory | |
| FD.02 | RCR | Data Collection/ Management | Data Management | 1.2.16 | The System shall apply a timestamp to each record at the point of ingestion to preserve data lineage and enable historical traceability. | Functional | RCR | Desirable | |
| FD.02 | RCR | Data Collection/ Management | Data Management | 1.2.17 | The System shall associate each record with a source tag (e.g., system ID, customer ID, file name, ingestion job ID) for validation, rollback, and audit purposes. | Functional | RCR | Desirable | |
| FD.02 | RCR | Data Collection/ Management | Data Management | 1.2.18 | The System shall make raw billing and usage data queryable by State-level system administrators and other State-authorized user roles, to support ad hoc queries, validation checks, and troubleshooting activities. | Functional | RCR | Mandatory | |
| FD.02 | RCR | Data Collection/ Management | Data Management | 1.2.19 | The System shall ensure scalability of the raw data store to handle large volumes of input (e.g., hundreds of millions of Mainframe usage records monthly). | Functional | RCR | Mandatory | |
| FD.04 | RCR | User Experience | UX | 1.5.1 | The System shall provide a responsive web interface that adjusts dynamically to different screen sizes (desktop, tablet, and smartphone) without loss of functionality. | Functional | RCR | Mandatory | |
| FD.04 | RCR | User Experience | UX | 1.5.2 | The System shall ensure that all core billing operations available on desktop (e.g., invoice viewing, reporting, notifications) are also accessible through mobile devices. | Functional | RCR | Desirable | |
| FD.04 | RCR | User Experience | UX | 1.5.3 | The System shall support access via standard mobile web browsers (e.g., Safari, Chrome, Edge) without requiring additional plug-ins. | Functional | RCR | Desirable | |
| FD.04 | RCR | User Experience | UX | 1.5.4 | The System shall provide a mobile-optimized navigation structure (e.g., collapsible menus, touch-friendly controls) to ensure usability on smaller screens. | Functional | RCR | Desirable | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.1 | The System shall allow State-level system administrators to create new user roles. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.2 | The System shall allow State-level system administrators to define a name and description for each user role. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.3 | The System shall allow State-level system administrators to assign one or more permissions to a user role during or after user role creation. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.4 | The System shall allow State-level system administrators to edit the name, description, and permissions of an existing user role. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.5 | The System shall allow State-level system administrators to delete an existing user role, if no users are assigned to the role. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.6 | The System shall maintain a list of customers and customer billing codes imported daily from FI$Cal. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.7 | The System shall allow State-level system administrators to assign multiple billing codes to a user. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.8 | The System shall allow State-level system administrators to revoke or change the user role(s) assigned to a user account at any time. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.9 | The System shall log changes to user role assignments for auditing purposes, including the State-level system administrators performing the change with date and timestamp. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.10 | The System shall enforce access controls based on the authenticated user’s effective permissions, ensuring segregation of duties and restricting access to users and data within the user’s assigned agency or department. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.11 | The System shall deny access to system functions, features, or data if a user lacks the appropriate permission. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.12 | The System shall provide detailed error messages when a user attempts to access a restricted resource or action, so that the error is clearly defined. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.13 | The System shall allow the State-level system administrator to assign a unique User ID to each user added to the system. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.14 | The System shall allow users to reset their own passwords. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.15 | The System shall allow a State-level system administrator to reset user passwords. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.16 | The System shall require users to successfully answer security challenge questions to reset their passwords. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.17 | The System shall assign a unique User ID to every user. | Functional | IBA | Mandatory | |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.18 | The System shall adhere to the follow password standards: |
a. Passwords must be at least 15 characters long.
b. Passwords must not contain login username or any part of a first or last name.
c. Passwords may not contain alpha or numeric representations of calendar months or years.
d. Assigned or temporary user passwords must be changed upon first login.
e. Default device/application passwords must be changed before use.
f. Passwords must be changed immediately if compromised.
g. Passwords should not be a single word in any language, slang, dialect, jargon, etc.
h. Blank or empty passwords are prohibited.
i. Password must contain at least one upper case letter, at last one lower case letter, at least one numeral, and at least one special character.
| Functional | IBA | Mandatory | ||||||
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.19 | The System shall support automated email messaging to all users for specific business requirements, such as but not limited to: password reset, temporary passwords, password expiration notifications, etc). | Functional | IBA | Mandatory |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.20 | The System shall maintain SCO and Data Center Users. | Functional | IBA | Mandatory |
| FM.01 | IBA | Administrative | Roles and Permissions | 1.1.21 | The System shall deny authentication and access for any user attempting to register or log in with a personal emaill address from non-authorized domains (e.g., Gmail, Yahoo, Outlook.com, iCloud, or similar). | Functional | IBA | Mandatory |
| FM.02 | DISO | Administrative | Roles and Permissions | 1.1.22 | The System shall comply with National Institute of Standards and Technology (NIST) special Publication (SP) 800-53 revision 5. (https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home) |
NIST Family: Identification and Authentication (IA) IA-1, IA-2, IA-3, IA-4, IA-5, IA-6, IA-7, IA-8, IA-11, IA-12.
| Functional | DISO | Mandatory | |||||||
| FM.03 | RCR | Administrative | Environment | 1.1.23 | The System shall provide a no-code or low-code design environment where authorized users can create and deploy workflows, forms, dashboards, and reports without requiring programming knowledge. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.24 | The System shall allow State-level system adminstrators to define workflow logic, conditional rules, and approval paths through guided configuration tools rather than scripting. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.25 | The System shall provide a configuration file or user interface (UI) for managing data sources, including the ability to define ingestion rules, field mappings, and transformation rules without writing code. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.26 | The System shall support version control for workflows, forms, and dashboards to ensure changes are tracked, reversible, and auditable. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.27 | The System shall allow State-level system administrators to preview and validate workflows/forms/dashboards before deployment into production environments. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.28 | The System shall provide automated error handling, validation, and alerting mechanisms within the no/low-code environment to reduce risk of misconfiguration. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.29 | The System shall allow for the scheduling of workflow execution (e.g., daily, weekly, monthly) and the ability to trigger workflows based on defined events or conditions. | Functional | RCR | Mandatory | |
| FM.03 | RCR | Administrative | Environment | 1.1.30 | The System shall support export/import of workflow configurations to facilitate migration between environments (Dev, Test, Training, Prod). | Functional | RCR | Mandatory | |
| FM.04 | DISO/EA | Administrative | Environment | 1.1.31 | The System shall comply with National Institute of Standards and Technology (NIST) special Publication (SP) 800-53 revision 5. (https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home) | ||||
| NIST Family: Configuration Management Family (CM) CM-1, CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-8, CM-9, CM-10, CM-11, CM-12. | Functional | DISO/EA | Mandatory | ||||||
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.32 | The System shall provide three parallel sandbox environments: Development, Test, Training. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.33 | The System shall isolate each sandbox enviornment from the production environment but fully replicate production environment functionality (configurations, integration, and application behavior) in each sandbox environment to allow testing and validation of configurations prior to their deployment. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.34 | The System shall provide sandbox environments (Development, Test, Training) that integrate with CDT's Mainframe development and test environments. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.35 | The System shall provide sandbox environments (Development, Test, Training) with transformation logic that mirrors the Production environment so that it is deployable and testable per environment, allowing safe iteration without affecting Production data flows. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.36 | The System shall provide sandbox environments (Development, Test, Training) that communicate with the same CDT Mainframe environment as Production (or a dedicated test region of the mainframe, if feasible). | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.37 | The System shall provide provide sandbox environments (Development, Test, Training) with data flows, message formats, and protocols between the application and the CDT Mainframe environment identical to Production. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.38 | The System shall maintain security protocols and authentication mechanisms for the sandbox environments (Development, Test, Training) consistent with Production. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.39 | The System shall support on demand data cloning capabilities that allow selected portions or full copies of Production data to be replicated into the any of the three sandbox environments (Development, Test, Training). | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.40 | The System shall allow simulation of billing scenarios (e.g., new service codes, adjusted rate structures, account hierarchy changes) using cloned or synthetic data in any of the three sandbox environments (Development, Test, Training). | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.41 | The System shall provide configurable options to select data cloning scope (e.g., by fiscal period, customer ID, account code, service type). | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.42 | The System shall generate detailed billing reports during simulations to allow users to validate expected results. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.43 | The System shall allow simulation of rate changes before production go-live, validating impacts on invoice amounts, customer roll-ups, and downstream reports. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.44 | The System shall allow authorized users to run parallel test billing cycles in the sandbox environment and compare results to baseline production runs to validate accuracy. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.45 | The System shall support rollback of sandbox environment data or reset to a clean state after billing simulation is complete by a State-level system administrator. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.46 | The System shall support regression testing by providing stored results from previous test billing runs, enabling comparison across versions. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.47 | The System shall provide tools to validate configuration and data changes within the sandbox environment prior to deployment to production. | Functional | RCR/IBA | Mandatory | |
| FM.05 | RCR/IBA | Administrative | Environment | 1.1.48 | The System shall allow validated configurations (e.g., rate changes, workflow modifications) tested in sandbox to be promoted to production through a controlled deployment process, with full version tracking and rollback capability. | Functional | RCR/IBA | Mandatory | |
| FM.06 | RCR | Administrative | Data Retention | 1.1.49 | The System shall retain all utilization and billing data for a minimum of five State fiscal years (Current Fiscal Year + 4 prior fiscal Years). | Functional | RCR | Mandatory | |
| FM.06 | RCR | Administrative | Data Retention | 1.1.50 | The System shall retain service subscription/consumption data, rate structures and service codes applicable during each billing period, customer identifiers (IDs, account codes, service categories), invoice records (summary, detailed, point-in-time), and adjustments/credits/reversals. | Functional | RCR | Mandatory | |
| FM.06 | RCR | Administrative | Data Retention | 1.1.51 | The System shall allow authorized users to query historical data by fiscal year, service type, customer ID, or account code. | Functional | RCR | Mandatory | |
| FM.06 | RCR | Administrative | Data Retention | 1.1.52 | The System shall flag data older than 5 years to be archived or purged in compliance with CDT retention policy. | Functional | RCR | Mandatory | |
| FM.06 | RCR | Administrative | Data Retention | 1.1.53 | The System shall log all archival and purge activities for transparency. Log data shall be kept for one (1) year. | Functional | RCR | Desirable | |
| FM.07 | RCR | Administrative | Cost Recovery | 1.1.54 | The System shall allow administrators to create and store customer names with a maximum of 40 characters. | Functional | RCR | Mandatory | |
| FM.07 | RCR | Administrative | Cost Recovery | 1.1.55 | The System shall restrict creation and modification of customer names to State-level administrators only (e.g., Administrators). | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.56 | The System shall be able to consume a daily/weekly file from FI$CAL to capture all Customer IDs and Department/Agency name. | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.57 | The System shall support Account Codes ranging from 3 to 20 characters, with configurable rules for format and structure (e.g., alphanumeric, prefixes). | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.58 | The System shall support both parent/child hierarchies (Customer ID roll-ups) and many-to-many relationships between customer IDs and account codes. | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.59 | The System shall allow authorized users to create, edit, deactivate, or retire Customer IDs and account codes while preserving history for audit purposes. | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.60 | The System shall maintain backward compatibility so historical invoices and reports still reference the correct codes used at the time. | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.61 | The System shall validate that each Customer ID and account code is unique across the system to prevent duplication. | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.62 | The System shall validate and flag when the first 3 characters of an entered Account Code do not match one of the stored customer account code prefixes | Functional | RCR | Mandatory | |
| FM.08 | RCR | Administrative | Cost Recovery | 1.1.63 | The System shall apply configurable business rules such as allowable length, character restrictions, and required associations (e.g., a customer record cannot exist without at least one account code). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.64 | The System shall allow State-level administrators to define and maintain service categories (e.g., Mainframe Services, Network Services, Cloud Hosting). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.65 | The System shall allow each service category (e.g., Mainframe Services, Network Services, Cloud Hosting) to be assigned metadata or linked data such as description, owner, cost center, and related rate models. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.66 | The System shall support hierarchical service categories (parent/child structures). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.67 | The System shall allow administrators to define rate codes tied to specific services (e.g., CPU-HRS, STORAGE-GB, NETWORK-PORT). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.68 | The System shall allow rate codes to be linked to specific unit of measure (e.g., per hour, per GB, per connection). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.69 | The System shall support effective-dating of rate codes, so that historical billing can be tied to the correct point-in-time rates. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.70 | The System shall allow administrators to create new service categories or rate codes without requiring vendor custom development. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.71 | The System shall provide a guided configuration interface to add new services and billing items/files. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.72 | The System shall allow newly added services to be integrated into billing logic immediately upon activation. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.73 | The System shall allow State-Level system administrators to edit service categories and rate codes (e.g., renaming, updating descriptions, updating formulas). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.74 | The System shall support bulk updates to service rates, rather than applying individual updates to each rate. For instance, if there are 5% increases across multiple rates, rather than updating each rate code, the system shall allow user to choose all service codes, and apply the increase to all. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.75 | The System shall allow service categories and rate codes to be directly linked to rate structures (flat, tiered, prorated). | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.76 | The System shall validate that each record is tied to a valid service category and rate code before billing. | Functional | RCR | Mandatory | |
| FM.10 | RCR | Administrative | Cost Recovery | 1.1.77 | The System shall maintain historical visibility of inactive or retired services for audit purposes. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.78 | The System shall support defining fixed, flat rates for services independent of usage volume, associated to service/rate structures. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.79 | The System shall support prorated charges when services are provisioned, upgraded, or terminated mid-billing cycle. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.80 | The System shall calculate prorated charges automatically based on start/end date and applicable rate formula. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.81 | The System shall support both time-based proration (e.g., daily/hourly) and percentage-based proration. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.82 | The System shall allow State-level administrators to define rate calculation formulas using configuration, not code. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.83 | The System shall support rate calculation formulas including but not limited to: percent-to-total, threshold-based logic, caps, floor pricing. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.84 | The System shall allow new rate structures to be added or modified through an administrative UI. | Functional | RCR | Mandatory | |
| FM.11 | RCR | Administrative | Cost Recovery | 1.1.85 | The System shall apply rate structures automatically to ingested usage records during billing runs. | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.20 | The System shall provide a secure web interface for uploading files with role-based access control. | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.21 | The System shall process hundreds of millions ingested Mainframe data lines each month (including daily, weekly and monthly frequencies). | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.22 | The System shall provide a configurable queuing mechanism to manage ingestion order/sequence. | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.23 | The System shall scale to add new data sources without major reconfiguration. | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.24 | The System shall validate imported data against field definitions (length, type, required values). | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.25 | The System shall log all ingestion/file upload attempts with success/failure outcomes. | Functional | RCR | Mandatory | |
| FM.12 | RCR | Data Collection/ Management | Data Collection | 1.2.26 | The System shall generate alerts for failed integrations/file upload (e.g., missing file, API outage, invalid data). | Functional | RCR | Mandatory | |
| FM.13 | IBA | Data Collection/ Management | Data Collection | 1.2.27 | The System shall provide predefined API specifications and data layouts for each interface type, data types and field structures. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.28 | The System shall allow State-level system administrators to configure data ingestion processes to run on predefined schedules, including daily, weekly, and monthly frequencies. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.29 | The System shall provide a dashboard to monitor the status of data ingestion jobs (e.g., pending, running, successes, failed). | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.30 | The System shall allow State-level system administrators to initiate ad hoc (on-demand) data ingestion processes. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.31 | The system shall provide a user interface through which State-level system administrators can define, edit, and delete data ingestion schedules. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.32 | The System shall allow State-level system administrators to specify the time of day for scheduled data ingestion processes. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.33 | The System shall support multiple concurrent ingestion configurations, each with its own schedule, data source, and processing logic. | Functional | IBA | Mandatory | |
| FM.14 | IBA | Data Collection/ Management | Data Collection | 1.2.34 | The System shall allow State-level system administrators to pause or disable any ingestion schedule without deleting its configuration. | Functional | IBA | Mandatory | |
| FM.15 | IBA | Data Collection/ Management | Data Collection | 1.2.35 | The System shall provide direct integration to ingest structured data formats including but not limited to JSON, XML, and flat files (CSV, TXT). | Functional | IBA | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.36 | The System shall support conditional logic (e.g., trigger ingestion if job status = success; send alert if failure). | Functional | RCR | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.37 | The System shall allow sequencing of workflows across multiple data sources (e.g., import raw CPU file, validate, then transform into billing table). | Functional | RCR | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.38 | The System shall generate alerts if expected events do not occur within a defined time window (e.g., ESP job normally runs at 2 a.m.; alert if missing by 4 a.m.). | Functional | RCR | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.39 | The System shall support concurrent ingestion triggers from multiple schedulers or systems. | Functional | RCR | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.40 | The System shall process ingestion events within a target time (e.g., initiate workflow within 30 seconds of job completion notification). | Functional | RCR | Mandatory | |
| FM.16 | RCR | Data Collection/ Management | Data Collection | 1.2.41 | The System shall prevent duplicate processing by ensuring that the same event only triggers one ingestion run, even if it is received more than once. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.42 | The System shall provide a secure, browser-based user interface for manual data upload. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.43 | The System shall support uploads from standard devices (desktop, laptop, tablet). | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.44 | The System shall reject unsupported file formats and provide clear error messaging. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.45 | The System shall enforce data layout standards, including required columns, field lengths, and data types. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.46 | The System shall allow users to correct and re-upload failed files without requiring system administrator intervention. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.47 | The System shall log each upload event by User ID, file name, file size, date/time, number of records ingested vs. rejected. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.48 | The System shall store metadata (e.g., source file name, upload timestamp) with ingested records for audit purposes. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.49 | The System shall route validated uploaded data into the same ingestion pipeline as automated or API-fed data. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.50 | The System shall tag manually uploaded data for distinction from automated feeds. | Functional | RCR | Mandatory | |
| FM.17 | RCR | Data Collection/ Management | Data Collection | 1.2.51 | The System shall support rollback for failed manual uploads if errors are discovered post-ingestion. | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.52 | The System shall allow only authorized users (with appropriate role/permissions) to initiate, enter, and approve corrections or adjustments. | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.53 | The System shall allow adjustments for both debit and credit billing items by inputting line item corrections to a single service charge or multiple line items to correct multiple past misbillings. | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.54 | The System shall allow adjustments to any value. | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.55 | The system shall allow adjusters to input a justification/note for the adjustment as an unpublished tagged comment to the record(s). | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.56 | The System shall validate adjustments against business rules (e.g., ensuring total cannot be negative, currency is consistent, adjustments fall within defined fiscal periods). | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.57 | The System shall automatically update the associated billing ledger once corrections are approved. | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.58 | The System shall support a configurable approval workflow by State-level administrators for adjustments, ensuring segregation of duties | Functional | RCR | Mandatory | |
| FM.18 | RCR | Data Collection/ Management | Data Management | 1.2.59 | The System shall allow adjustments to be routed to a reviewer or approver before posting. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.60 | The System shall reject incoming records with missing required fields from being saved to the target data store. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.61 | The System shall validate the length of each data field against its defined minimum and maximum length constraints. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.62 | The System shall validate each field against its defined data type (e.g., string, integer, date, Boolean). | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.63 | The System shall validate that date and time fields follow the specified format. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.64 | The System shall reject or flag any record where fields exceed length limits or do not meet schema expectations. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.65 | The System shall identify duplicate records based on configurable matching logic (e.g., same Customer ID, Service Code, Usage Amount, and Billing Period). | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.66 | The System shall support options for handling duplicates by flagging for review in a validation queue. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.67 | The System shall produce an exception report listing all rejected or flagged records including reason for exception. Error reporting shall include summary of pass/fail counts, error categories, and first/last error timestamps | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.68 | The System shall allow State-level administrators to configure automated reminder notifications for unresolved file ingestion, processing errors, or data errors. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.69 | The system shall allow automated errors from exception reports to be sent via both email and in-app alerts within five minute of error detection to both the user who initiated the upload and other assigned users (supporting billing team members, system administrators, manager) to ensure redundancy in issue awareness. | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.70 | The System shall allow State-level administrators to configure validation rules without vendor development (e.g., update required fields, adjust duplicate detection logic). | Functional | RCR | Mandatory | |
| FM.19 | RCR | Data Collection/ Management | Data Management | 1.2.71 | The System shall support rule versioning, so the State can track when changes were made to validation logic and by whom. Rules shall be stored for 5 fiscal years | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.72 | The System shall detect and flag exceptions across ingestion, validation, transformation, invoice generation, and export steps. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.73 | The System shall classify exceptions by type (e.g., schema/format error, missing required field, referential integrity, duplicate record, checksum mismatch, job timeout, permissions/auth failure, downstream endpoint failure). | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.74 | The System shall record context for data ingestion, such as: source system, file/job name, job ID, trigger (schedule/event/manual), environment (Dev/Test/Training/Prod), start/end timestamps, and initiating user/service account. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.75 | The System shall make exception reports available in the UI and exportable as CSV and PDF (minimum), preserving applied filters. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.76 | The System shall store generated Exception Reports in a centralized logging directory with timestamped filename. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.77 | The System generate Exception Reports, which include: Unique Report ID, Timestamp to include data and time, User ID/Source (e.g., who initiated the upload or the source system), File Name of the uploaded file or source system, File Type of the uploaded file, Failure Type (e.g., scheme mismatch, validation error, etc.), Detailed Error Log, Suggested Action, failed jobs and retries. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.78 | The System shall allow targeted retry at the job level (re-run the whole load) and record level (reprocess only failed records). | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.79 | The System should allow administrators to configure how failed transactions or processes are retried, including settings for retry batch size, wait time between retries (back-off interval), maximum number of retry attempts, whether retries stop once a successful attempt occurs, etc. | Functional | RCR | Desirable | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.80 | The System shall provide root-cause hints (e.g., “Field Account Code length > allowed 10”; “Unknown Service Code ‘XYZ’—add mapping or correct source”) for uploads/validation/ingestion exceptions. | Functional | RCR | Desirable | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.81 | The System shall log every retry/resend with who, when, what changed, prior status, new status, and outcomes (success/fail counts). | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.82 | The System shall produce a record-level report when given a file with schema violations, which enumerates each field error and blocks commit of failed records. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.83 | The System's error/exception notifications shall include the error type, affected source system or file, timestamp, job ID, and suggested remediation steps. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.84 | The System shall, where applicable, link the alert to the corresponding exception report or log for troubleshooting. | Functional | RCR | Mandatory | |
| FM.20 | RCR | Data Collection/ Management | Data Management | 1.2.85 | The System shall allow State-level administrators to configure notification preferences (e.g., notify only on critical errors, notify specific groups for specific data sources). | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.86 | The System shall assign a unique version ID to each snapshot created before an external data upload. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.87 | The System shall retain the system snapshot data for a State-configurable retention period (e.g., 30 days by default). | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.88 | The System shall take a full snapshot of the current system state before an external data upload is initiated, and shall provide metadata for each snapshot, including timestamp, user who initiated the upload, and data source name. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.89 | The System shall log the initiation, progress, and completion status of all data uploads. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.90 | The System shall record all changes (create, update, delete) performed by the external upload operation. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.91 | The System shall associate all changes made during the external upload with the corresponding snapshot version ID. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.92 | The System shall allow State-level administrators to restore data to a prior system state by selecting an available pre-change snapshot and executing a rollback through the user interface or an API. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.93 | The System shall prompt for confirmation before executing a rollback operation. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.94 | The System shall rollback all data changes made by the upload without affecting unrelated records. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.95 | The System shall ensure that a rollback operation is atomic - either all changes are reverted successfully, or none are. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.96 | The System shall allow rollback for snapshots that are within the State-configured retention period. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.97 | The System shall generate a report detailing the changes that were undone during a rollback. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.98 | The System shall notify State specified users or user groups of a successful or failed rollback operation. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.99 | The System shall provide a list of available rollback points (snapshots) with metadata. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.100 | The System shall allow users to view the differences between the current data and a selected snapshot. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.101 | The System shall display a warning if a rollback operation will result in data loss or conflicts. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.102 | The System shall restrict rollback and restore actions to users with State-specified permissions. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.103 | The System shall provide alerts during the rollback process should dependent processes (e.g., reports, calculations, data transformation operations) would be overwritten or deleted. | Functional | RCR | Desirable | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.104 | The System shall automatically abort an external upload and restore the system to its prior state when a defined critical error occurs. Critical errors include file corruption, schema or structural failure, system write or transaction failure, security validation failure, or error conditions that exceed configured fatal-error thresholds. | Functional | RCR | Mandatory | |
| FM.21 | RCR | Data Collection/ Management | Data Management | 1.2.105 | The System shall provide clear error messages if a rollback cannot be completed due to constraints (e.g., locked data, missing dependencies). | Functional | RCR | Mandatory | |
| FM.22 | RCR | Data Collection/ Management | Data Management | 1.2.106 | The System shall automatically apply metadata tags to all incoming records during ingestion to tag source identifier, load timestamp, source file size, file name and ID. | Functional | RCR | Mandatory | |
| FM.22 | RCR | Data Collection/ Management | Data Management | 1.2.107 | The system shall use file-level metadata and expected file controls (e.g., file name, file type, source system, billing period, sequence number, batch ID, file data/time, record count, checksum, etc.) to identify duplicate files and detect missing files or informaiton during ingestion. | Functional | RCR | Mandatory | |
| FM.22 | RCR | Data Collection/ Management | Data Management | 1.2.108 | The System shall use the source identifier and load timestamp to identify a set of records for rollback to a previous state. | Functional | RCR | Mandatory | |
| FM.22 | RCR | Data Collection/ Management | Data Management | 1.2.109 | The System shall maintain version history for records that have been reloaded or corrected for one year. | Functional | RCR | Mandatory | |
| FM.22 | RCR | Data Collection/ Management | Data Management | 1.2.110 | The System shall allow users with appropriate permissions to query metadata fields for investigation or audit purposes. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.111 | The System shall provide a staging layer A staging layer where data is temporarily stored, allowing State-level Administrators to review usage, cost, and customer before final billing and invoicing occurs | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.112 | The System shall automatically run validations against staged records to confirm required fields are completed (e.g., service code, customer ID, account code). | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.113 | The System shall automatically run validations against staged records to confirm data type and field length. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.114 | The System shall automatically run validations against staged records to confirm rate codes are active. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.115 | The System shall allow corrected records to be resubmitted for validation and staging. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.116 | The System shall support configurable retry rules. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.117 | The System shall only allow billing calculation and invoice generation after all staged records have been approved by a designated State-level Administrator. | Functional | RCR | Mandatory | |
| FM.23 | RCR | Data Collection/ Management | Data Management | 1.2.118 | The System shall generate audit reports showing validation outcomes, approvals, rejections, and corrections. | Functional | RCR | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.119 | The System shall support a staging layer for loaded/ingested data that enables data validation, format standardization, mapping to internal billing structures, and exception handling. | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.120 | The System shall allow administrators to map incoming fields (e.g., Acct_ID, CustCode) to the system’s internal fields (e.g., Customer_ID). | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.121 | The System shall provide a visual interface for defining and maintaining mapping rules. | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.122 | The System shall support basic transformations for date formats, numeric conversions (e.g. rounding, decimals), and string trimming (spaces). | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.123 | The System shall allow simple “if/then” logic to handle variations in incoming data (e.g., if data element, replace with default code). | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.124 | The System shall flag and log transformation errors, generate exception reports for the transformation issues, and prevent errors from being finalized into billing until corrected. | Functional | RCR/IBA | Mandatory | |
| FM.24 | RCR/IBA | Data Collection/ Management | Data Transformation | 1.2.125 | The System shall maintain audit trails of all transformation rules created, modified, or deleted. | Functional | RCR/IBA | Mandatory | |
| FM.25 | RCR | Reporting/Invoicing | Invoicing | 1.3.1 | The System shall allow authorized users to trigger ad hoc invoice runs outside of the standard billing cycle. | Functional | RCR | Mandatory | |
| FM.25 | RCR | Reporting/Invoicing | Invoicing | 1.3.2 | The System shall ensure that ad hoc invoices use the same calculation logic, rate codes, and billing rules as scheduled invoices. | Functional | RCR | Mandatory | |
| FM.25 | RCR | Reporting/Invoicing | Invoicing | 1.3.3 | The System shall prevent invoice generation when required data elements are missing or incomplete. | Functional | RCR | Mandatory | |
| FM.25 | RCR | Reporting/Invoicing | Invoicing | 1.3.4 | The System shall display and apply the correct pricing (service rates) for each service based on the effective dates selected within an invoice report. | Functional | RCR | Mandatory |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .