P3.5: prop-acc 启用子模块嵌套(adhoc/),应对大型业务域扩展
背景: 单纯按 UDAS 严格扁平,prop-acc/scenarios/ 装齐 7 子模块后预计 100-150 篇 .md 单一文件夹,Explorer 无法浏览、Quartz folder page 无法阅读。 扩展规则(已写入 SKILL.md 多域章节 + multi-domain.md 第 10 节): - 单类型文件夹文件数 > 30 且能按业务子模块分组时,启用嵌套 - 路径:<domain>/<type>/<sub-feature>/<file>.md - 文件名去 <sub-feature>- 前缀(路径已表达) - title 三段式:<domain> · <sub-feature> · <名> - frontmatter 新增 sub_feature 字段(便于 RAG 过滤) - 跨子模块文档落在 <domain>/<type>/(不进子文件夹),与"跨域→cross/"对称 本次迁移: - prop-acc/concepts/adhoc-*.md (3) → prop-acc/concepts/adhoc/*.md - prop-acc/scenarios/adhoc-*.md (25) → prop-acc/scenarios/adhoc/*.md - 每个文件:title 加 adhoc 段、aliases 追加旧 prop-acc · 前缀形式(兼容)、 新增 sub_feature: adhoc 字段 WikiLink 解析未受影响: - 既有 [[场景-A流-...]] 等 200+ 引用通过 aliases (含旧 basename) 解析 - 新引用可用 [[adhoc · 前台购买 IC 卡]] 或 [[prop-acc · adhoc · 前台购买 IC 卡]] - 各域 knowledge-map.md 内 WikiLink 全部仍有效 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Willie
209
prop-acc/scenarios/adhoc/audit-ic-card-stock-reconciliation.md
Normal file
209
prop-acc/scenarios/adhoc/audit-ic-card-stock-reconciliation.md
Normal file
@@ -0,0 +1,209 @@
|
||||
---
|
||||
title: prop-acc · adhoc · 场景 - 审计 - IC 卡库存与售出数对账
|
||||
aliases:
|
||||
- prop-acc · 场景 - 审计 - IC 卡库存与售出数对账
|
||||
- 场景 - 审计 - IC 卡库存与售出数对账
|
||||
- 场景-审计-IC卡库存与售出数对账
|
||||
tags:
|
||||
- 场景
|
||||
- prop-acc
|
||||
- 一次性收费
|
||||
- 业务场景
|
||||
- 审计对账
|
||||
audience:
|
||||
- 业务人员
|
||||
status: 已发布
|
||||
sub_feature: adhoc
|
||||
last_review: 2026-05-25
|
||||
code_version: 2026-05-22
|
||||
---
|
||||
|
||||
# 场景:IC 卡库存与售出数对账
|
||||
|
||||
物业月底核对:**系统记录卖出的 IC 卡数量** 是否等于 **库存盒里减少的物理 IC 卡数量**。
|
||||
|
||||
> [!warning] 系统不直接管物理库存
|
||||
> 本系统**只管财务**(收了多少钱),**不管实物**(IC 卡盒里还剩几张)。物理库存盘点是物业**独立的内部流程**,本场景描述如何用系统数据**辅助核对**物理库存。
|
||||
|
||||
## 典型情境
|
||||
|
||||
> [!example] 真实情境
|
||||
> 5 月 31 日,物业财务王姐做月度库存盘点。
|
||||
>
|
||||
> - 月初库存:100 张工本卡(已制好的空白 IC 卡)
|
||||
> - 月底盘点:剩 47 张
|
||||
> - 推断:**这个月用掉 53 张**
|
||||
>
|
||||
> 在 Filament 后台查"5 月 IC 卡售出数",**应该等于 53 张**。如果不等,需要排查。
|
||||
|
||||
## 业务人员视角
|
||||
|
||||
### 步骤 1:盘点物理库存
|
||||
|
||||
```
|
||||
1. 月初库存(从上月结存) 100 张
|
||||
2. 本月入库(新采购) +50 张
|
||||
3. 本月理论可用 150 张
|
||||
4. 月底盘点(数库存盒) -47 张
|
||||
─────────────────────────────────────
|
||||
5. 本月实际"消耗" 103 张
|
||||
```
|
||||
|
||||
### 步骤 2:从系统拉售出数据
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
COUNT(*) AS 售出订单数,
|
||||
SUM(quantity) AS 卡总张数
|
||||
FROM acc_ad_hoc_events ahe
|
||||
JOIN acc_rate_plans rp ON ahe.rate_plan_id = rp.id
|
||||
WHERE rp.name LIKE '%IC 卡%'
|
||||
AND ahe.occurred_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
|
||||
AND ahe.status = 'completed';
|
||||
```
|
||||
|
||||
输出例:
|
||||
```
|
||||
售出订单数:90 单
|
||||
卡总张数:103 张 (有些订单买多张)
|
||||
```
|
||||
|
||||
### 步骤 3:对账
|
||||
|
||||
```
|
||||
物理消耗 vs 系统售出
|
||||
103 vs 103 ✅ 完美一致
|
||||
```
|
||||
|
||||
或者:
|
||||
|
||||
```
|
||||
物理消耗 vs 系统售出
|
||||
103 vs 101 ❌ 差 2 张
|
||||
→ 物理少了 2 张 / 系统多算 2 张
|
||||
```
|
||||
|
||||
### 步骤 4:差额排查
|
||||
|
||||
#### 差额 > 0(物理消耗 > 系统售出)
|
||||
|
||||
**意味着**:卡发了但没记账。可能原因:
|
||||
|
||||
| 原因 | 处理 |
|
||||
|---|---|
|
||||
| 给 VIP 业户**免费**发卡(没收钱也没记录)| 物业政策合规,要补登记 0 元订单 |
|
||||
| 测试卡(写卡测试用了几张)| 算损耗 |
|
||||
| 业务人员私发 | **严重**,核查员工 |
|
||||
| 卡丢失 / 制卡失败报废 | 算损耗 |
|
||||
|
||||
#### 差额 < 0(物理消耗 < 系统售出)
|
||||
|
||||
**意味着**:记账了但卡没发。可能原因:
|
||||
|
||||
| 原因 | 处理 |
|
||||
|---|---|
|
||||
| 业户已付款但实物没拿(走 [[场景-异常-支付完成但实物发不出]])| 检查"待补发清单",物业还在保管 |
|
||||
| 录单时数量填错(多录了)| 检查录入异常订单,可能要 [[场景-取消-录错金额作废重做]] |
|
||||
| 业户付了款作废后忘了取回卡 | 物业归档 |
|
||||
|
||||
## 物理库存管理建议
|
||||
|
||||
> [!tip] 建议物业建一份独立的库存台账
|
||||
> 不在系统里(系统不管物理库存),但用 Excel / 纸质本子记:
|
||||
|
||||
```
|
||||
=== IC 卡库存台账 ===
|
||||
|
||||
日期 操作 数量 余额 经办人 备注
|
||||
2026-04-30 月初余结存 100 上月结存
|
||||
2026-05-03 采购入库 +50 150 李四 合同 #2026005
|
||||
2026-05-15 发给业户 -1 149 张三 房号 12-3-501
|
||||
2026-05-15 发给业户 -2 147 张三 房号 8-2-301
|
||||
...(每天明细)
|
||||
2026-05-31 月底盘点 47 王姐 实物数对
|
||||
```
|
||||
|
||||
每周/每月与系统数据对照。
|
||||
|
||||
## 系统流程
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 财务
|
||||
participant 物理库存
|
||||
participant Filament/DB
|
||||
participant 业务人员
|
||||
|
||||
Note over 财务: 月底
|
||||
财务->>物理库存: 数库存盒
|
||||
物理库存-->>财务: 47 张
|
||||
|
||||
财务->>财务: 计算消耗 = 100 + 50 - 47 = 103
|
||||
|
||||
财务->>Filament/DB: 查 5 月 IC 卡售出数
|
||||
Filament/DB-->>财务: 103 张
|
||||
|
||||
财务->>财务: 对账 ✅
|
||||
|
||||
Note over 财务: 若不一致
|
||||
|
||||
财务->>业务人员: 找差额
|
||||
业务人员-->>财务: 解释(免费发卡 / 录入错误 / 报废等)
|
||||
```
|
||||
|
||||
## 其他实物的对账方法
|
||||
|
||||
同样的方法可以对账:
|
||||
|
||||
| 实物 | 系统侧查询 |
|
||||
|---|---|
|
||||
| **装修出入证** | `SUM(quantity) WHERE rate_plan.name LIKE '%装修出入证%'` |
|
||||
| **泳票(纸质)** | `SUM(quantity) WHERE rate_plan.name LIKE '%泳票%'` |
|
||||
| **充值码 / 充值卡** | `COUNT(*) WHERE rate_plan.name LIKE '%充值%'` |
|
||||
|
||||
## 常见问题
|
||||
|
||||
> [!question] 为什么系统不直接管物理库存?
|
||||
> 物理库存涉及**采购 / 入库 / 报废 / 盘点** 等独立流程,可能跨多个仓库 / 多种实物。**绑到收费系统里会让收费系统过重**。最佳实践:
|
||||
> - 库存独立做(Excel / 专门的 ERP)
|
||||
> - 收费系统专注于"卖出与收钱"
|
||||
> - 月底用对账连接两者
|
||||
|
||||
> [!question] VIP 业户免费发卡,系统里要建 0 元订单吗?
|
||||
> **强烈建议建**。便于库存对账。Filament 后台支持金额 = 0(不会失败)。备注栏注明"VIP 免费 + 审批单号"。
|
||||
|
||||
> [!question] 制卡过程中报废的卡怎么入账?
|
||||
> 系统侧**不录任何订单**(没有交易发生)。在库存台账里**算损耗**:
|
||||
> ```
|
||||
> 日期 制卡失败报废 -1 余额 X 备注 测试新读卡器
|
||||
> ```
|
||||
|
||||
> [!question] 差额超过 10 张能不能不查?
|
||||
> **强烈不建议**。差额是**审计预警信号**,长期不查可能掩盖:
|
||||
> - 员工私发
|
||||
> - 财务挪用
|
||||
> - 系统漏录
|
||||
>
|
||||
> 建议:**月度差额 > 5 张必须给出书面解释**。
|
||||
|
||||
## 与"现金对账"的区别
|
||||
|
||||
| 对账类型 | 对账对象 | 数据源 | 频率 |
|
||||
|---|---|---|---|
|
||||
| [[场景-审计-月底现金对账\|现金对账]] | 系统订单 vs 收银抽屉 | 数据库 + 物理现金 | 每月 |
|
||||
| **库存对账(本场景)** | 系统订单 vs 物理库存盒 | 数据库 + 物理盘点 | 每月 |
|
||||
| 作废抽查 | 作废订单的事由记录 | 数据库 meta 字段 | 每季 |
|
||||
|
||||
三种对账**独立做但互相印证** —— 现金对账过了但库存不对,可能是 VIP 免费发卡;反之可能是手工卖了卡没录系统。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[场景-A流-前台购买IC卡]] — 售出的数据来源
|
||||
- [[场景-审计-月底现金对账]] — 财务对账
|
||||
- [[场景-审计-作废事由抽查]] — 第三种对账
|
||||
|
||||
## 异常分支
|
||||
|
||||
- 物理少了 → 内部排查
|
||||
- 系统少了 → 找漏录单 / 补登记
|
||||
- 多个月持续不一致 → **必查清** 不能拖
|
||||
Reference in New Issue
Block a user