uniprop-manual/prop-acc/scenarios/adhoc-audit-void-reason-sampling.md

---
title: prop-acc · 场景 - 审计 - 作废事由抽查
aliases:
  - 场景 - 审计 - 作废事由抽查
  - 场景-审计-作废事由抽查
tags:
  - 场景
  - prop-acc
  - 一次性收费
  - 业务场景
  - 审计对账
audience:
  - 业务人员
status: 已发布
last_review: 2026-05-25
code_version: 2026-05-22
---

# 场景:作废事由抽查

物业**财务 / 内审 / 上级** 定期抽查作废订单,验证**作废原因记录是否完整、合理**。防止业务人员**滥用作废功能**(挪用现金、做账漏洞)。

> [!info] 为什么这个对账很重要?
> 一次性收费的 [[场景-已收款作废\|已收款作废]] 涉及**资金退还**。如果业务人员说"作废了"但没真退,**或者作废用来掩盖之前的挪用**,系统层面看不出来 —— 必须靠**事由记录抽查**反向追查。

## 典型情境

> [!example] 真实情境
> 6 月份内审来检查 5 月份记录:
> - 5 月共有 8 笔已收款作废订单
> - 总作废金额 ¥1,520
>
> 内审要求**逐笔出示作废原因 + 资金处理凭证**。

## 业务人员视角(被抽查方)

### 内审会问什么

每笔作废订单,内审会问:

| 问题 | 你要拿出的证据 |
|---|---|
| 为什么作废? | meta.voided_reason 完整记录 |
| 谁审批的? | meta.voided_by 是 supervisor 级别员工 |
| 资金怎么处理的? | 现金退还签字 / 微信退款记录 / POS 撤销凭证 |
| 业户确认收到退款了吗? | 业户签字 / 微信沟通截图 |
| 是否后续重新下单? | 如果是,关联新订单号 |

### 准备资料

```
1. 拉出 5 月份所有作废订单
2. 按订单号逐一整理:
   ├── 截图 Filament 后台订单详情
   ├── 截图 meta.voided_* 字段(JSON 格式)
   ├── 附微信退款记录 / 现金签收单
   └── 附业户沟通截图(如果有)
3. 装订成册交内审
```

## 查作废订单的 SQL

```sql
SELECT
    ahe.id,
    ahe.created_at AS 创建时间,
    ahe.meta->>'voided_at' AS 作废时间,
    ahe.meta->>'voided_reason' AS 作废原因,
    ahe.meta->>'voided_by' AS 操作员ID,
    u.name AS 操作员姓名,
    ahe.amount AS 金额,
    rp.name AS 项目,
    cup.user_id AS 业户ID
FROM acc_ad_hoc_events ahe
JOIN acc_rate_plans rp ON ahe.rate_plan_id = rp.id
LEFT JOIN community_community_user_profiles cup ON ahe.community_user_profile_id = cup.id
LEFT JOIN users u ON CAST(ahe.meta->>'voided_by' AS INTEGER) = u.id
WHERE ahe.status = 'voided'
  AND CAST(ahe.meta->>'voided_at' AS TIMESTAMP) BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
ORDER BY ahe.meta->>'voided_at' DESC;
```

## 健康的作废 vs 可疑的作废

> [!success] 健康的作废(对账通过)

```
voided_reason: "录入金额错误 ¥400 应为 ¥40。已通过微信原路退款 ¥400,
              业户已确认收到。重新下一笔正确订单 CO-XXX。
              处理人:王XX(夜班柜员)"
voided_at: 2026-05-15 19:23:45
voided_by: 5 (王XX)

✅ 内审评价:
- 原因清晰
- 资金处理写明(微信原路退款)
- 业户确认
- 关联新订单(可追溯)
```

> [!failure] 可疑的作废(内审会盯)

```
voided_reason: "作废"
voided_at: 2026-05-20 17:55:30
voided_by: 5

❌ 内审评价:
- 原因仅一个字,无解释
- 没说资金处理
- 没说业户是否确认
- 没说后续是否重做
- **强烈建议核查:是否有挪用现金嫌疑**
```

## 抽查指标

业务人员的"作废率"是一个重要指标:

```
作废率 = 作废订单数 / 总订单数

健康水平:< 3%
警戒水平:3% ~ 5%
严重水平:> 5%(必须人工核查每笔)
```

某员工的作废率**显著高于团队均值** → 可能是工作能力差(经常录错)或可疑(挪用)。

### 按员工统计

```sql
SELECT
    u.name AS 员工,
    COUNT(*) FILTER (WHERE ahe.status = 'voided') AS 作废笔数,
    COUNT(*) FILTER (WHERE ahe.status = 'completed') AS 完成笔数,
    ROUND(100.0 * COUNT(*) FILTER (WHERE ahe.status = 'voided')
        / NULLIF(COUNT(*), 0), 2) AS 作废率
FROM acc_ad_hoc_events ahe
LEFT JOIN users u ON CAST(ahe.meta->>'voided_by' AS INTEGER) = u.id
WHERE ahe.occurred_at >= '2026-05-01'
GROUP BY u.id, u.name
ORDER BY 作废率 DESC;
```

输出例:
```
员工     | 作废笔数 | 完成笔数 | 作废率
李XX     |    1    |   320    |  0.31% ✅
张XX     |    3    |   280    |  1.07% ✅
王XX     |   12    |    95    | 12.63% ❌ 必查
```

## 系统流程

```mermaid
sequenceDiagram
    participant 内审
    participant 业务人员
    participant Filament/DB
    participant 业务流程

    Note over 内审: 季度审计

    内审->>Filament/DB: 拉作废订单 + meta
    Filament/DB-->>内审: 8 笔 ¥1520

    内审->>业务人员: 出示原因 + 资金凭证
    业务人员->>业务人员: 整理资料(微信截图、签收单)
    业务人员-->>内审: 交付

    内审->>内审: 逐笔检查
    alt 原因清晰 + 资金凭证完整
        内审-->>业务人员: ✅ 通过
    else 原因模糊 / 凭证不全
        内审-->>业务人员: ❌ 要求补充说明
        业务人员->>业务流程: 联系业户补凭证
        业务人员-->>内审: 补充材料
    end

    Note over 内审: 整理审计报告 → 上报集团
```

## 防止作废滥用的设计

> [!info] 系统设计上的几道防线
>
> 1. **作废必须填原因** —— Filament UI 强制必填 textarea
> 2. **记录 voided_by** —— 留谁的责任
> 3. **记录 voided_at** —— 留时间戳
> 4. **不能修改 voided_reason** —— 写入后只读
> 5. **作废后状态不可恢复** —— 不能事后"撤销作废"
>
> 这五道防线让作废操作**完全留痕**,事后审计有据可查。

## 常见问题

> [!question] 业务人员作废后能不能"修改作废原因"?
> **不能**。meta 字段写入后不可修改。如果原因写错了,需要技术介入(直接改数据库)且留**修改记录**。

> [!question] 内审能否要求**所有作废订单**逐笔检查?
> 可以。健康的物业**所有作废都应该有可解释的原因**。如果某月作废多了一倍以上,**全数检查**是必要的。

> [!question] 业户主动撤单(Pending 单)也要审吗?
> 不需要。Pending 单作废**没有资金涉及**(业户没付款),审计风险低。但 voided_reason 也应该清楚(便于业户体验问题排查)。

> [!question] 系统能不能自动报警"高作废率员工"?
> 当前**没有自动报警**。可以挂 TODO:
> - 定时 job(每日 / 每周)算每个员工作废率
> - 超阈值的发邮件 / 微信通知管理员
> - 等业务方明确反馈再做

> [!question] 已经处罚过的员工,历史作废记录还能看到吗?
> **能**。作废记录**永久保留**,即使员工离职、被开除,他名下的所有操作都在数据库里有据可查。

## 与其他对账的对照

| 对账类型 | 对账对象 | 重点 |
|---|---|---|
| [[场景-审计-月底现金对账\|现金对账]] | 系统订单 vs 物理现金 | 钱在不在 |
| [[场景-审计-IC卡库存与售出数对账\|库存对账]] | 系统订单 vs 物理库存 | 货在不在 |
| **作废事由抽查(本场景)** | 作废订单的 meta 字段 | **原因合不合理 + 责任清不清楚** |

三种对账**完整覆盖** "钱、货、人" 三个维度。健康物业每月都做。

## 相关概念

- [[概念-AdHocEvent状态机]] — Voided 状态的不可逆性
- [[场景-已收款作废]] — 作废操作的入口
- [[场景-取消-录错金额作废重做]] — 健康的作废示例

## 异常分支

- 内审发现重大问题 → 报集团 / 公安(挪用)
- 业务人员书写不规范 → 加强培训 + 重写 meta 模板