Files
uniprop-manual/prop-acc/scenarios/adhoc-audit-month-end-cash-reconciliation.md
Willie b7c0cd6e0c 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>
2026-05-25 20:44:43 +08:00

7.2 KiB

title, aliases, tags, audience, status, last_review, code_version
title aliases tags audience status last_review code_version
prop-acc · 场景 - 审计 - 月底现金对账
场景 - 审计 - 月底现金对账
场景-审计-月底现金对账
场景
prop-acc
一次性收费
业务场景
审计对账
业务人员
已发布 2026-05-25 2026-05-22

场景:月底现金对账

财务每月月底核对前台收的现金系统记录是否一致。也叫"日结" / "月结"。

[!info] 给谁看 主要给财务人员。业户不需要懂这部分。

典型情境

[!example] 真实情境 5 月 31 日,物业财务王姐准备月度结账。她要核对一次性收费 5 月份前台收的现金总额是否等于收银抽屉的实际现金

核心问题:三个数要对得上

graph LR
    A[A 系统记录<br/>CollectionOrder 表] --> D{对账}
    B[B 收据汇总<br/>Receipt 表] --> D
    C[C 物理现金<br/>抽屉点数] --> D
    D --> E[✅ 三方一致]
    D --> F[❌ 不一致 → 追查]

    classDef record fill:#dbeafe
    classDef physical fill:#fef3c7
    classDef result fill:#dcfce7
    classDef fail fill:#fee2e2

    class A,B record
    class C physical
    class E result
    class F fail

如果三者一致,通过。如果不一致,需要逐笔排查。

业务人员视角(财务)

步骤 1:拉系统数据

在 Filament 后台:

路径 1:CollectionOrders 列表
├── 筛选:collection_completed_at 在 2026-05-01 ~ 2026-05-31
├── 筛选:collection_type = AdHoc
├── 筛选:payment_method = "现金"
└── 求和:actual_amount

得到 → A 系统记录(现金部分)

或直接走 SQL:

SELECT
    COUNT(*) AS 订单数,
    SUM(actual_amount) AS 现金总额
FROM acc_collection_orders
WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND collection_type = 'ad_hoc'
  AND payment_method LIKE '%现金%'
  AND status = 'completed';

步骤 2:对照 Receipt 表(验证内部一致)

SELECT
    COUNT(r.id) AS 收据数,
    SUM(r.amount) AS 收据总额
FROM acc_receipts r
JOIN acc_collection_orders co ON r.collection_order_id = co.id
WHERE co.collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND co.collection_type = 'ad_hoc'
  AND co.payment_method LIKE '%现金%'
  AND r.status = 'issued';

A 和 B 应该完全相等(因为每笔订单生成一张收据,金额完全对应)。如果不等 → 数据库不一致问题,严重,要技术介入。

步骤 3:点物理现金

财务到前台:

  1. 打开收银抽屉
  2. 数所有钞票 + 硬币
  3. 减掉初始备用金(通常 ¥500-1000)
  4. 得到 C 现金部分

步骤 4:对照 A vs C

情况 含义 处理
A = C 完美对账 月底归档,提现到银行
A > C(系统多) 现金少了 找差额:可能丢失 / 找零错 / 员工挪用
A < C(现金多) 现金多了 找差额:可能少录单 / 找零少给 / 业户给多了没退

差额 ≥ ¥10 都要逐笔排查。

步骤 5:逐笔排查(差额情况)

1. 列出所有现金订单清单(订单号 + 金额 + 时间 + 业户)
2. 对照前台手工日志(如果有)/ 监控录像
3. 找到可疑的几笔:
   ├── 录入时间晚了几小时(可能延后录入)
   ├── 金额特殊(整数 / 没零头)
   └── 业户名字可疑
4. 联系业户 / 当事员工核实

多渠道场景

实际场景不只有现金。一次性收费可能有 5+ 种支付渠道:

渠道 对账依据
现金 收银抽屉点数
微信支付 微信商户后台流水
支付宝 支付宝商户后台流水
POS 刷卡 银行账单
银行转账 对公账户流水

每种渠道独立对账:

SELECT
    payment_method,
    COUNT(*) AS 订单数,
    SUM(actual_amount) AS 总额
FROM acc_collection_orders
WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND collection_type = 'ad_hoc'
  AND status = 'completed'
GROUP BY payment_method;

输出例:

现金       125 笔  ¥3,820
微信       42 笔   ¥1,260
支付宝     18 笔   ¥540
POS刷卡    8 笔   ¥280
─────────────────────────
合计       193 笔  ¥5,900

财务对照每个渠道的外部对账单。

系统流程

sequenceDiagram
    participant 财务
    participant Filament/DB
    participant 前台
    participant 微信商户
    participant 支付宝商户
    participant 银行

    财务->>Filament/DB: 月度筛选 + 求和(按支付方式)
    Filament/DB-->>财务: 各渠道金额

    财务->>前台: 点物理现金
    前台-->>财务: 抽屉总额

    财务->>微信商户: 查流水
    微信商户-->>财务: 微信总收款

    财务->>支付宝商户: 查流水
    支付宝商户-->>财务: 支付宝总收款

    财务->>银行: 查对公账单
    银行-->>财务: 转账 + POS 流水

    财务->>财务: 逐渠道对账
    财务->>财务: 不一致逐笔排查

常见问题

[!question] 系统多了 ¥30,可能是什么原因?

  • 业户付完拿走货,职员忘了给找零(¥50 收 ¥20 商品,找零给少了)
  • 当天工作交接,前班的现金没全部移交
  • 销售退款没退,系统已记作废但前台没退现金给业户

[!question] 系统少了 ¥50,可能是什么原因?

  • 漏录单(收了钱忘录系统)
  • 找零给多了
  • 业务人员临时挪用(严重,要核查)

[!question] 每次差几块钱(< ¥10)能忽略吗? 不建议。差小钱不一定是 bug,但长期累积 + 不追究 = 内部审计黑洞。建议:

  • 差 < ¥10 也记录追查
  • 差 ≥ ¥100 当周必查清

[!question] 业务人员能修改历史订单的支付方式吗? 不能(订单 Completed 后不可编辑)。如果发现某笔订单的 payment_method 录错(比如填了"现金"实际是"微信"),走 场景-已收款作废 + 重新录入。

[!question] 月底前的几小时高峰怎么处理? 5 月 31 日 23:59 录入的订单 vs 6 月 1 日 00:01 录入,在 SQL 里严格按时间戳归属。建议月底前后 30 分钟减少操作,避免跨月归类争议。

月度报表的标准格式(建议)

=== 一次性收费 2026 年 5 月对账报告 ===

【系统数据】
现金:    ¥3,820  (125 笔)
微信:    ¥1,260  (42 笔)
支付宝:  ¥540    (18 笔)
POS刷卡: ¥280    (8 笔)
─────────────────────
合计:    ¥5,900  (193 笔)

【外部数据】
收银抽屉点数:        ¥3,820  ✅
微信商户后台:        ¥1,260  ✅
支付宝商户后台:      ¥540    ✅
银行 POS 入账:       ¥280    ✅

【差额追查】
无

【作废订单(对照)】
本月作废:   3 笔  ¥150
其中 Pending 作废:  2 笔(超时/撤单)
其中 Completed 作废: 1 笔(已退款 ¥30,银行原路)

【签字】
财务:______ 物业经理:______ 日期:______

相关概念