Files
uniprop-manual/prop-acc/scenarios/deposit/audit-long-pending-accounts.md
Willie a98bdaf98e deposit 子模块 · 轮 2:18 场景 + 知识地图收尾
写 18 个场景到 prop-acc/scenarios/deposit/,覆盖 7 类业务:

📥 缴纳(3):
- deposit-first-time-renovation(张阿姨首次缴 5000)
- deposit-additional-topup(陈先生追加 2000)
- deposit-on-behalf-by-company(王装修代 3 户业主缴 15000)

💰 退款(3):
- refund-full-no-damage(无损全退)
- refund-partial-after-forfeit(扣 800 退 4200)
- refund-with-payment-channel-switch(现金缴 → 银行转账退)

⚠️ 扣罚(2):
- forfeit-damage-public-area(墙面损坏扣 800)
- forfeit-violation-no-permit(未报备私自动工违约扣 3000)

🧊 冻结/解冻(2):
- freeze-during-dispute(纠纷期间冻结)
- unfreeze-after-mediation(调解后解冻)

🔒 结清(2):
- close-after-zero-balance(余额清零自动 Closed)
- close-manual-with-zero-balance(主动关空账户)

🚨 强制关账(3,Frozen + 有余额困境):
- force-close-refund(全退,鉴定无责)
- force-close-forfeit(全扣,仲裁全责)
- force-close-retain(资金保留,业户失联/装修方倒闭)

🛡️ 异常/审计(3):
- exception-deposit-on-frozen(冻结状态尝试缴款被三层守护拦截)
- audit-monthly-deposit-balance(月度三方对账:账面 == 银行专户 == 流水净值)
- audit-long-pending-accounts(超 2 年未关账户分类清理)

每篇结构:典型情境 → 业户视角 → 业务人员视角 → 系统流程(mermaid)→
流水台账 → 常见问题 → 异常分支 → 相关文档。

收尾:
- prop-acc/maps/deposit-knowledge-map.md:18 场景全部 ,加完成 callout
- prop-acc/maps/knowledge-map.md:deposit 行状态改 " 25 篇"
- prop-acc/index.md:同步

deposit 子模块完整覆盖:6 概念 + 18 场景 + 1 知识地图 = 25 篇。

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 22:40:19 +08:00

6.6 KiB

title, aliases, tags, audience, status, sub_feature, last_review, code_version
title aliases tags audience status sub_feature last_review code_version
prop-acc · deposit · 场景 - 长期未关账户排查
长期未关账户
押金账户清理
audit-long-pending-accounts
场景-长期押金账户排查
场景
prop-acc
保证金
审计
财务
业务人员
已发布 deposit 2026-05-25 2026-05-22

场景:长期未关账户排查

物业财务季度 / 半年做一次扫描,找出开户时间过长但仍未关账的账户,逐个调查原因并推进结清。是合规要求,避免代管负债无限累积。

典型情境

[!example] 真实情境 物业财务王主管在 2026 年中做"超 2 年未关押金账户"清理:

  • 系统里查出 23 个账户开户时间超过 2 年,状态仍 Active
  • 其中 18 个是装修早已结束但物业 / 业户都忘了走退款流程
  • 4 个是业户已搬走联系不上
  • 1 个是因为业户提出物业服务费纠纷,押金账户被业户作为"筹码"

主管要逐个推进:能联系的发起退款、联系不上的走 retain、纠纷的走 freeze。

业务人员视角

第 1 步:扫描出长期账户

-- 开户超 2 年仍 Active 的账户
SELECT
  id,
  payer_name,
  payer_contact,
  balance,
  status,
  opened_at,
  TIMESTAMPDIFF(MONTH, opened_at, NOW()) AS months_open,
  community_id,
  asset_id,
  community_user_profile_id
FROM acc_deposit_accounts
WHERE status IN ('active', 'frozen')
  AND opened_at < NOW() - INTERVAL 2 YEAR
ORDER BY opened_at ASC;

也可按需要调整阈值:1 年 / 6 个月 / 3 个月。装修押金正常应在 3-6 个月内结清,超过 1 年就异常。

第 2 步:分类并定调处理路径

类型 表现 处理路径
A. 装修早已结束,忘了退 装修施工证已过期、业户已正常入住 主动联系业户 → 走 refund-full-no-damage
B. 业户失联 联系方式打不通、上门无人 等失联期到法律保留期 → force-close-retain
C. 装修方已倒闭(三方账户) 公司账户、付款人已注销 走法律程序 + force-close-retain
D. 业户与物业有纠纷 业户用押金作筹码 freeze-during-dispute 冻结 → 调解
E. 数据问题(开账户没缴款) balance=0 但状态仍 Active [[close-manual-with-zero-balance
F. 装修中(正常) 施工合同仍有效、近期有缴款 / 扣罚动作 不动

第 3 步:逐个推进

对每条记录:

  1. ViewDepositAccount 看流水台账(最后一次操作是什么时候、是什么)
  2. 查业户联系方式 + 上次联系记录
  3. 决定处理路径
  4. 执行(走对应场景)
  5. 在内部清理 Excel 记录"已处理:[路径],日期:[XX-XX-XX]"

第 4 步:出报告

# 2026 年 Q2 超 2 年未关押金账户清理报告

## 总数:23
- A. 退款关账(联系业户成功):16
- B. 资金保留(联系不上):4
- C. 已 freeze 进入调解:1
- D. 主动关账(数据异常):2

## 资金处置
- 退款总额:¥85,400
- retain 总额:¥18,200(进入"待业户领取"清单)
- 仍 Active(纠纷调解中):¥5,000

## 后续动作
- retain 4 户:每年节点扫描,业户出现立即处理
- freeze 1 户:跟进调解
- 建议:开户超过 12 个月物业管家主动跟进("您家装修是否结束?")

系统流程

flowchart TD
  A[季度/半年触发] --> B[运行 SQL 扫描长期账户]
  B --> C[人工分类]

  C --> D[A. 联系业户成功<br/>→ refund-full-no-damage]
  C --> E[B. 业户失联<br/>→ force-close-retain]
  C --> F[C. 装修方倒闭<br/>→ force-close-retain + 法务]
  C --> G[D. 业户纠纷<br/>→ freeze-during-dispute]
  C --> H[E. 数据异常 balance=0<br/>→ close-manual-with-zero-balance]
  C --> I[F. 正常装修中<br/>→ 不动]

  D --> J[出清理报告]
  E --> J
  F --> J
  G --> J
  H --> J

常见问题

[!question] 为什么要做这种清理? 几个理由:

  • 合规:代管负债不应无限累积。账面挂着却没业务对应的押金,审计会问"这笔钱凭什么还在你这"
  • 资金占用:这些押金占用专户额度,物业不能用,但也算合规成本
  • 追溯困难:超 5 年的账户对应的业务人员、装修方都可能不在了,处理起来更难
  • 风险积累:业户某天突然要求退款,如果联系不上当年的相关人 / 凭证,物业会很被动

[!question] 开户多久算"长期"? 取决于业务:

  • 装修押金:超 6 个月就开始关注,超 12 个月主动联系,超 24 个月强制处理
  • 入驻押金 / 设备押金:可能合理保留多年,看合同期
  • 保留(retain)账户:理论上随时可被业户领回,无时间限制

各物业自行设阈值,SQL 查询调整 INTERVAL 即可。

[!question] 长期账户找业户但业户拒接 / 无回应,算失联吗? 一般做法:

  • 物业管家上门 3 次 + 短信 3 次 + 电话 5 次,均无回应 → 视为失联
  • 书面记录(每次联系尝试的日期、方式、结果)
  • 满足"已尽合理联系义务"的法律标准
  • 然后走 force-close-retain

直接 ForceClose retain 没问题,但建议先 freeze-during-dispute 等一段时间(例如 30 天),给业户最后机会。

[!question] retain 的资金最终怎么变成"非负债"? 各地法规不同,但通常:

  • 长期无主资金(5-10 年以上),走司法程序判归
  • 街道办 / 民政部门接管
  • 部分地区可转入物业自有资金(需特别审批)

走完这些流程后,在该 retain 账户 meta 加 transferred_to_* 字段记录归属,但账户本身仍 Closed(不重启)。账面上的资金责任随转出而清。

[!question] 这个扫描应该自动化吗? 可以,但不推荐自动执行操作:

  • 自动 SQL 扫描可定时跑,生成报告
  • 任何账户状态变更必须人工触发 —— 不能让定时任务自动 forceClose
  • 自动操作 = 没人对结果负责 = 出错没人查

[!question] 报告做完没人处理怎么办? 这是物业内部管理问题,不是系统问题。建议:

  • 报告产生 = OKR 指标(财务团队 KPI)
  • 上报物业总经理 + 法务,纳入月度运营回顾
  • 长期堆积的报告 = 内控失效的信号

异常分支

  • 找出大批"无缴款"账户 → 业务流程可能有缺陷,改"业户开始装修当天才开户"流程
  • 找出疑似挪用资金的账户 → 法务 + 内部审计介入
  • retain 账户的余额合计很大(影响财务报表)→ 设单独"代管资金 - 待处置"科目

相关文档