vault backup: 2026-05-26 00:23:07
This commit is contained in:
229
prop-acc/scenarios/meter/read-with-photo-proof.md
Normal file
229
prop-acc/scenarios/meter/read-with-photo-proof.md
Normal file
@@ -0,0 +1,229 @@
|
||||
---
|
||||
title: prop-acc · meter · 场景 - 抄表拍照存证(物理表头照片)
|
||||
aliases:
|
||||
- 抄表拍照
|
||||
- 照片存证
|
||||
- read-with-photo-proof
|
||||
- 场景-抄表拍照存证
|
||||
tags:
|
||||
- 场景
|
||||
- prop-acc
|
||||
- 计量表
|
||||
- 抄表
|
||||
- 存证
|
||||
audience:
|
||||
- 业户
|
||||
- 业务人员
|
||||
- 抄表员
|
||||
status: 已发布
|
||||
sub_feature: meter
|
||||
last_review: 2026-05-26
|
||||
code_version: 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 不为空)
|
||||
- 点击图标 → 弹出照片预览
|
||||
- 可下载原图
|
||||
|
||||
### 业户争议处理
|
||||
|
||||
业户来电话 / 上门质疑账单:
|
||||
|
||||
1. 王主管打开对应 reading
|
||||
2. 调出 photo_url 照片
|
||||
3. 与业户当面 / 视频核对
|
||||
4. 业户接受 → 案件了结
|
||||
5. 业户仍质疑 →
|
||||
- 物业派人**现场再读一次**(若表还在)
|
||||
- 若现场读数与照片一致 → 业户更难反驳
|
||||
- 若现场读数与照片不一致 → 表可能故障 / 数据有问题,走 [[replace-broken-meter|换表]] / [[exception-readings-locked-after-bill|修正流程]]
|
||||
|
||||
## 拍照流程图
|
||||
|
||||
```mermaid
|
||||
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]]
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [[reading-source-and-photo-proof]]
|
||||
- [[read-single-meter-manual]]
|
||||
- [[read-batch-via-excel-import]]
|
||||
- [[read-via-iot-remote-source]]
|
||||
- [[exception-high-consumption]]
|
||||
- [[decommission-and-locking]]
|
||||
Reference in New Issue
Block a user