Email
overseas@ytsanchuan.com
-
- En
-
-
A monthly billing run can expose problems that a polished software demonstration overlooks. A reading may reach the wrong customer account, arrive after the billing cutoff, or appear inconsistent after a meter replacement. Before choosing a platform, a utility needs to see how its staff will identify and resolve these situations.Water meter reading software collects and organizes consumption records for review and transfer to billing. Its usefulness depends on the complete path from the original measurement to an accepted billing record. A practical evaluation should follow that path using the utility’s own meter inventory, sample files and operating rules.
Before comparing water meter software, agree what a usable record must contain. This gives operations, billing and IT teams a common basis for evaluating demonstrations.Start with three groups of information:
Identity: meter serial number, service point, customer account and the dates during which that meter served the account.
Measurement: reading value, unit, measurement timestamp and whether the value is a cumulative register reading or consumption for an interval.
Processing history: receipt time, collection method, validation status and a record of any correction.
These fields answer different questions. Measurement time establishes when consumption was recorded. Receipt time shows when the platform received the record. Both matter when a delayed transmission crosses a billing cutoff.Ask the supplier to preserve the original record when a correction is made, together with the reason and the person who approved it. During a billing dispute, staff should be able to trace the figure on an account back to its source.
A protocol name on a product page is a starting point for a compatibility discussion. Your evaluation also needs the meter model, communication module, firmware version, available fields and intended collection schedule.A utility evaluating an AMR system for water meter data collection should supply a representative route file. Ask the vendor to import it, identify unread meters, correct an account mapping and upload the same file again. The demonstration should show how the system handles repeat submissions and preserves the route history.For a mixed fleet, include records from the meter types that will remain in service during the transition. Check whether operators can identify the source of each reading and apply the appropriate validation rules without maintaining separate customer identities for each collection method.Document the tested configuration. A successful demonstration with one meter and receiver combination should lead to a written compatibility record for that combination.
For AMI water meter systems, specify the required measurement interval, acceptable arrival time and treatment of readings that arrive after an interruption.Ask for three separate views during the pilot:
Which expected active meters have reported within the agreed period.
Which billable accounts have valid readings for the required billing window.
Which exported records the billing system has accepted or rejected.
A successful transmission can still produce an unusable record if the unit, account or timestamp is wrong. A successful file export also needs an acceptance response from the receiving system.Keep meter counts and account counts distinct, especially where one account has several meters or a meter changes during the billing period. Agree the population behind each measure before comparing results.
Use a small, representative set of records to test how staff will handle exceptions. Agree the expected result before the demonstration so that the test produces a clear acceptance record.
| Pilot scenario | What the utility should demonstrate | Evidence to retain |
|---|---|---|
| Duplicate submission | Submit an identical meter record twice and confirm that accepted usage is unchanged | Import history and duplicate handling result |
| Delayed reading | Submit a reading after the cutoff and apply the agreed late-data rule using its measurement time | Original timestamps and the resulting account status |
| Meter replacement | Close the old meter, open the new meter and retain both contributions to the billing period | Replacement date, closing and opening registers, consumption calculation |
| Different units | Import equivalent volumes in litres and cubic metres and check the normalized result | Original unit, conversion and normalized volume |
| Unmapped account | Import a record with no valid account, resolve the mapping and repeat the release step | Exception history and the corrected account association |
| Rejected billing export | Return a rejection from the billing system, correct the issue and resubmit without duplicating accepted usage | Rejection response, correction history and acceptance confirmation |
A meter replacement provides a useful calculation test. In an illustrative billing period, the old meter opens at 1,000 m³ and is removed at 1,018 m³. Its replacement starts at 0 m³ and closes the period at 6 m³. Total consumption is 18 + 6 = 24 m³.The software should account for both meters over their respective service periods. Subtracting the old opening register from the new closing register would produce an invalid result. Ask the operator to show where the replacement history and calculation remain visible.Then ask a member of your own team to repeat a correction after training. This helps reveal whether routine exception handling is practical for the people who will run the system.
Sanchuan’s software portfolio includes NetPlus for AMR and AMI workflows and YUN ZHI LIAN for broader utility management. Utilities considering a smart water management system can use the published capabilities below to prepare a focused demonstration.
| Sanchuan platform | Publicly listed collection and integration capabilities | A useful demonstration request |
|---|---|---|
| NetPlus Remote Reading System | Walk-by, drive-by and fixed-network collection; usage report export; API integration with billing or SCADA | Import a representative collection file and trace its records through to the billing response |
| YUN ZHI LIAN | Meter data integration, DMA zone monitoring and flow anomaly alerts; APIs linking SCADA, GIS and billing systems | Show how a meter record, an operational alert and a billing export remain identifiable across the connected systems |
Use these published capabilities to shortlist a solution, then verify the proposed project configuration. Request a sample field map, export file or interface response so your team can check the data path before implementation.This also helps define the project scope. Record which functions belong to the meter, communication service, software platform and billing application, and identify who will resolve issues at each handoff.
Choose water meter reading software by testing how actual records move from collection to an accepted billing result. Define the required fields, run exception scenarios, verify calculations across meter replacements and document who resolves rejected records. Compare platforms using the same sample data and acceptance criteria so the decision reflects the work your utility must perform every billing cycle.To discuss a project with Sanchuan, prepare the meter inventory, representative reading files, billing requirements and pilot acceptance criteria. These materials give the technical discussion a concrete starting point. Choose a platform your team can verify with its own meter data before committing to a wider rollout.
Water meter reading software helps utilities collect, organize and check consumption readings before transferring accepted data to billing. When comparing solutions, confirm that staff can trace each exported value to its original meter record, measurement time and customer account.
A platform may support both, but compatibility should be tested with the proposed meters and collection equipment. Include AMR route files and AMI interval records in the demonstration. Check that both use consistent account identifiers while retaining their collection method, timestamps and validation status.
Run a complete test using representative readings and the intended billing interface. Reconcile account IDs, units, billing periods and consumption totals. Include a rejected record and a corrected resubmission, then confirm that the receiving system acknowledges acceptance without duplicating previously accepted usage.
It should retain the old and new meters against the same service point with their respective service dates. Calculate consumption from the old meter’s opening and closing registers, then add consumption from the replacement meter. Preserve the replacement history so staff can explain the total.
Confirm how authorized staff can export original readings, corrected values, account mappings and change histories. Review available formats, retention periods, access permissions and the process for transferring records to another system. Ask the supplier to demonstrate an export that your team can inspect independently