7.5 KiB
title, aliases, tags, audience, status, sub_feature, last_review, code_version
| title | aliases | tags | audience | status | sub_feature | last_review | code_version | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · meter · 场景 - 抄表拍照存证(物理表头照片) |
|
|
|
已发布 | meter | 2026-05-26 | 2026-05-22 |
场景:抄表拍照存证(物理表头照片)
抄表员录入读数同时上传现场拍的物理表头照片(photo_url),作为业户事后质疑账单时的关键凭证。配合 read-single-meter-manual 流程使用。
典型情境
[!example] 真实情境 张阿姨 6 月初收到 5 月电费账单 ¥168(280 度),她声称"我家平时就 100 多度,不可能这么多":
- 王主管打开后台 → 找 E-501 的 5 月 reading → 看
photo_url- 照片清晰显示:表头数字 5,280(日期戳 2026-05-26,环境信息可识别为张阿姨家配电箱)
- 拿照片给张阿姨看 → 业户无话可说(确实读数是 5,280)
- 王主管协助分析:可能近期家里某电器异常耗电(空调 24 小时开?旧冰箱故障?)
- 业户回去自查 → 发现儿子用了电烤箱 + 空气炸锅一个月 → 接受账单
拍照存证避免了一次纠纷。
抄表员视角(李师傅)
拍照要点
每张表抄表时,拍 1-2 张照片:
| 角度 | 内容 |
|---|---|
| 正面特写 | 表头数字清晰可读(关键!) |
| 环境照 | 表 + 周围环境(配电箱 / 房号牌),证明是哪家的表 |
照片要素:
- 清晰(对焦,光线足够)
- 包含表头读数全部位数(不要遮挡)
- 时间戳(手机 EXIF 元数据自动带)
- GPS(若手机 App 支持,更好)
录入
后台 / 抄表 App 上的 reading 录入 form 含 photo_url 字段:
| 字段 | 填什么 |
|---|---|
| 当前读数 | 5280 |
| 拍照 | 上传刚才的照片(或 App 直接拍照上传) |
| 备注 | 选填,如"电表正常,环境无异常" |
上传后照片存储到对象存储(S3 / OSS),photo_url 字段存对外可访问 URL。
[!info] 强制度看物业政策
- 严格物业:Form 上
photo字段->required(),无照片不能提交- 建议物业:Form 可空,UI 上有"建议拍照"提示
- 宽松物业:Form 可空,无提示
当前实现看
MeterReadingsRelationManager的 form 配置。生产环境强烈推荐严格模式。
业务人员视角
查照片
后台 → 计量表 → ViewMeter → Reading 列表(MeterReadingsRelationManager):
- 每条 reading 显示"照片"图标(若 photo_url 不为空)
- 点击图标 → 弹出照片预览
- 可下载原图
业户争议处理
业户来电话 / 上门质疑账单:
- 王主管打开对应 reading
- 调出 photo_url 照片
- 与业户当面 / 视频核对
- 业户接受 → 案件了结
- 业户仍质疑 →
- 物业派人现场再读一次(若表还在)
- 若现场读数与照片一致 → 业户更难反驳
- 若现场读数与照片不一致 → 表可能故障 / 数据有问题,走 replace-broken-meter / exception-readings-locked-after-bill
拍照流程图
sequenceDiagram
participant 李师傅
participant 物理表
participant 手机App
participant ObjectStorage[对象存储 S3/OSS]
participant 数据库
李师傅->>物理表: 现场观察读数
李师傅->>物理表: 拍照
李师傅->>手机App: 录入读数 + 选刚拍的照片
手机App->>ObjectStorage: 上传照片
ObjectStorage-->>手机App: 返回 URL
手机App->>数据库: 建 MeterReading + photo_url
业户视角
您会感受到什么
通常不感知 —— 抄表员拍照是物业内部流程。
唯一影响:
- 抄表员上门时可能要求"打开配电箱看表"(配合)
- 极端情况:业户怀疑抄表员拍假照(看清照片是否真的是自己家表 = 看背景环境)
您的权利
对账单有异议时有权要求:
- 看抄表照片
- 派人现场再读一次
- 提交业户自己拍的反证照片(若业户当时也拍了)
拍照的额外用途
除业户争议外,照片还有其他价值:
| 用途 | 怎么用 |
|---|---|
| 审计追溯(年审 / 监管) | 抽查某月某些 reading 的 photo_url,验证抄表真实性 |
| 抄表员考核 | 检查抄表员是否真去现场(对比 GPS / 时间 / 环境) |
| 培训新人 | 给新抄表员看老抄表员的照片范例 |
| 争议预防 | 业户知道有照片在,主动质疑减少 |
拍照的成本
| 成本 | 说明 |
|---|---|
| 抄表员时间 | 每张表 +5-10 秒 → 1,000 张表 +1-2 小时 |
| 手机存储 | 每张照片 1-5 MB → 1,000 张 = 几 GB / 月 |
| 对象存储 | 几 GB / 月 ≈ 几元 / 月(阿里云 OSS / S3) |
| 长期累积 | 5 年 = TB 级,需归档策略 |
| 培训 | 抄表员要学会拍合格照片(对焦、清晰、含表头全部数字) |
整体成本可控,但需要持续投入。
拍照的法律意义
[!info] 业户法律纠纷时
在物业 vs 业户法律纠纷中,拍照照片是关键物证:
- 照片有时间戳 + GPS + 环境元数据(EXIF) → 可证明真实性
- 照片清晰显示读数 + 表号 → 可证明读数正确
- 法院通常采信 这类专业现场记录
物业完全没有拍照 → 只有业户口供 vs 物业账面数据 → 物业举证困难。
集抄(remote)与拍照的关系
集抄 reading(source=remote)通常无拍照:
- IoT 设备直接传数据,无相机
- IoT 设备本身就是凭证(机器读数 → 通常比人工准)
- 集抄掉线的兜底 read-single-meter-manual 仍要拍照
详见 reading-source-and-photo-proof"拍照存证"段。
常见问题
[!question] 业户拒绝抄表员进屋拍照怎么办? 公共部位的表(楼道电表、燃气表)通常装在外面,不用进屋。
入户表(水表常在厨房 / 卫生间)若业户拒绝:
- 协商上门时间(业户在家时)
- 业户自己拍照发给物业(部分物业接受)
- 长期拒绝 → 物业政策决定(警告 / 法律手段 / 估算用量)
[!question] 照片上传失败怎么办? 网络问题 / 对象存储故障:
- App 应有本地缓存机制(离线时存手机,联网时上传)
- 上传失败的 reading 应仍能提交(photo_url 为空但有备注"上传失败")
- 后续重传(若设计支持)
[!question] 照片存多久? 法律 / 业务规定:
- 中国通常 3-5 年(看物业法规)
- 与账单同周期(账单存多久,照片存多久)
- 长期归档(冷存储,如阿里云 OSS Archive)成本极低
[!question] 一张照片能证明哪张表是谁家的? 照片本身不能(看不出房号)。需配合:
- 环境识别(房号牌、门口装饰、邻居环境)
- 抄表员手写标注(若 App 支持)
- GPS 坐标(若 App 支持)
- 数据库 meter_id 关联(reading 关联 meter,meter 关联 asset)
[!question] 业户对照片质疑"那不是我家的表"怎么办? 调取原始 EXIF 数据(时间戳、GPS、设备型号)→ 证明照片真实性。物业可派人现场对照确认表号物理一致。
异常分支
- 单录(本场景前置)→ read-single-meter-manual
- 批量导入(无拍照)→ read-batch-via-excel-import
- 集抄(无拍照)→ read-via-iot-remote-source
- 拍照后业户仍质疑高用量 → exception-high-consumption