P3+P4+P5: prop-acc 迁移到多域 UDAS,新建 4 域骨架与顶层入口
P3 — prop-acc 30 文件迁移到多域 UDAS 结构:
- 3 概念:旧 prop-acc/一次性收费/概念-*.md
→ prop-acc/concepts/adhoc-*.md (kebab-case 英文)
- 25 场景:旧 prop-acc/一次性收费/场景-*.md
→ prop-acc/scenarios/adhoc-*.md
- 子文件夹 index.md → prop-acc/maps/knowledge-map.md (域内地图)
- prop-acc/index.md 重写为域首页(embed knowledge-map)
- 删除空目录 prop-acc/一次性收费/
每个迁移文件:
- title 加域前缀 "prop-acc · "
- aliases 含原 title (带空格) + 原文件名 basename (无空格),保证既有 [[...]] 引用解析
- status: stable → 已发布 / draft → 草稿 (UDAS 中文枚举)
- last_reviewed → last_review (UDAS 字段名)
- tags 补加 UDAS 类型分类 "概念" / "场景"
- 路径式 WikiLink 清除:
* [[../预存款/index|XX]] → [[预存款]]
* [[一次性收费/index|XX]] → [[prop-acc · 一次性收费索引]]
P4 — 4 个新业务域骨架:
- community (社区管理)
- administrative (行政人事)
- patrol (巡护工单)
- resident-portal (业户门户)
每域含 index.md (域首页) + maps/knowledge-map.md (域内地图模板)。
另补 cross/index.md + cross/maps/cross-domain-map.md。
P5 — 顶层入口:
- index.md: 站点首页 (Quartz 着陆点),embed domain-map
- maps/domain-map.md: 5 业务域 + cross 的索引表
迁移后状态:
- 共 50 篇 .md (30 原 + 8 跨域 stub + 4 域 index + 4 域 map + 2 cross + 2 root)
- 残留路径式 WikiLink: 0
- 残留英文 status: 0
- 残留 last_reviewed 字段: 0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Willie
235
prop-acc/scenarios/adhoc-audit-void-reason-sampling.md
Normal file
235
prop-acc/scenarios/adhoc-audit-void-reason-sampling.md
Normal file
@@ -0,0 +1,235 @@
|
||||
---
|
||||
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 模板
|
||||
Reference in New Issue
Block a user