Vault/uniprop-manual

Fork 0

Files

Willie 484d2e2e50 vault backup: 2026-05-25 14:04:39

2026-05-25 14:04:39 +08:00

7.4 KiB

Raw Blame History

title, tags, audience, status, last_reviewed, code_version

title

场景:作废事由抽查

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

[!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

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%(必须人工核查每笔)

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

按员工统计

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% ❌ 必查

系统流程

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

    Note over 内审: 季度审计

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

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

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

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

防止作废滥用的设计

[!info] 系统设计上的几道防线

作废必须填原因 —— Filament UI 强制必填 textarea

记录 voided_by —— 留谁的责任

记录 voided_at —— 留时间戳

不能修改 voided_reason —— 写入后只读

作废后状态不可恢复 —— 不能事后"撤销作废"

这五道防线让作废操作完全留痕,事后审计有据可查。

常见问题

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

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

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

[!question] 系统能不能自动报警"高作废率员工"? 当前没有自动报警。可以挂 TODO:

定时 job(每日 / 每周)算每个员工作废率

超阈值的发邮件 / 微信通知管理员

等业务方明确反馈再做

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

与其他对账的对照

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

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

异常分支

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

7.4 KiB Raw Blame History