b7c0cd6e0c
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>
5.5 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · 场景 - A 流 - 装修公司批量采购出入证 |
|
|
|
已发布 | 2026-05-25 | 2026-05-22 |
场景:装修公司批量采购出入证
与个人业户买装修证不同:大型装修公司同时承包小区里几十户装修,每户都要发出入证 —— 一次买 50-200 张的场景。
[!info] 主要给业务人员看 这个场景对业户(装修公司联系人)而言是"批量买 + 一笔结清";对业务人员是"录入快、对账难"。
典型情境
[!example] 真实情境 鸿基装修公司在小区里承包 12 户精装修业务,共需要 60 张出入证。公司财务下午到物业,要一次性办完 60 张 + 一张发票。
业户(装修公司联系人)视角
您要准备什么
| 材料 | 数量 |
|---|---|
| 公司营业执照复印件 | 1 份 |
| 法人 / 经办人身份证 | 1 份 |
| 每户的装修合同(原件 + 复印件) | 12 份 |
| 60 个工人的身份证复印件 | 60 份 |
| 可开发票的公司抬头 / 税号 | 用于开发票 |
流程
- 到物业前台,出示材料
- 物业核对身份和合同
- 物业算总价:60 张 × ¥30 = ¥1800
- 您付款(通常公司账户转账或 POS 公司卡)
- 拿到 60 张装修证 + 发票(发票流程独立)
- 把 60 张证按工地分发给工头
业务人员视角
关键策略:一笔订单 vs 多笔订单?
[!warning] 重要决策 60 张装修证,应该录成 1 笔订单(数量=60),还是 12 笔订单(每户一笔)?
| 录法 | 优点 | 缺点 |
|---|---|---|
| 1 笔订单(数量=60) | 操作快、收据 1 张 | 业户对账难,出问题作废只能整体作废 60 张 |
| 12 笔订单(每户 1 笔) | 业户能按户对账,作废粒度细 | 录入慢、收据多张 |
| 15-30 笔混合 | 灵活,按楼栋分 | 取决于业务习惯 |
推荐:按户分笔(12 笔订单)。原因:
- 每户的装修合同号、工人名册都不一样,对账时能精确到户
- 后续如果某户停工要作废,只影响那一户的几张证
- 发票可以多张合并出(发票流程不绑定订单数量)
Filament 录入(12 笔订单的版本)
1. 收公司财务的总金额 ¥1800
2. 对照装修合同清单,按户录入 12 笔:
├── 户 12-3-501,5 张装修证 ¥150
├── 户 12-3-502,4 张装修证 ¥120
├── ...
3. 12 笔订单的支付方式都填"公司转账"
4. 备注栏写"鸿基装修公司批量采购,合同号 XX"
5. 检查总金额 = ¥1800
6. 出 12 张收据 + 1 张发票(发票合并)
一笔订单的版本(快速版)
1. Filament 后台 → 一次性收费 → 新建
2. 业户:不绑定具体房号,填"鸿基装修公司"
3. 收费项目:装修出入证
4. 数量:60
5. 金额:1800
6. 支付方式:公司转账
7. 备注:"60 张,涉及房号:12-3-501, 12-3-502, ...(12 户)"
8. 提交
[!warning] 一笔录入的副作用 这笔订单的
community_user_profile_id不一定挂得上(装修公司不是常规业户)。 如果系统里没有装修公司的CommunityUserProfile,得先建一个"客户档案"再下订单。
系统流程
sequenceDiagram
participant 装修公司
participant 前台
participant 系统
participant 财务
装修公司->>前台: 60 张装修证 + 12 户合同
前台->>前台: 核对合同 + 工人名册
Note over 前台,系统: 推荐:按户分 12 笔
loop 每户
前台->>系统: 录入一笔 AdHocEvent
系统-->>前台: 收据 1 张
end
装修公司->>前台: 公司账户转账 ¥1800
前台->>系统: 12 笔订单状态 Completed
前台->>财务: 走发票合并流程
财务-->>装修公司: 发票 1 张(¥1800)
常见问题
[!question] 公司转账有时差,前台先发证还是先收款? 业界惯例是先入账后发证。技术上 12 笔订单可以先建 Pending 状态(B 流),等转账到账后再统一翻 Completed。
当前 A 流是即收即付,只能等款到账后录入。如果转账走 1-2 天,可以折中:
- 当天先录 Pending(用 B 流的
CreatePendingAdHocEventAction)- 到账日再批量翻 Completed
[!question] 业户要求开一张大发票 还是 12 张小发票? 发票流程独立于订单,系统不强制对应关系。多数公司要一张大发票(便于报销),物业方按业户需求开即可。
[!question] 60 张证录 12 笔太慢了,有批量录入吗? 当前 Filament 后台没有批量录入入口。如果业务上批量场景很多,可以考虑加一个"批量下单" Filament Action(类似 ImportMeterReadingsAction 的导入模式)。等业务方反馈再做。
[!question] 装修公司中途停工(只用了 30 张证)能退一半吗? 技术上每笔订单可以单独作废(详见 场景-已收款作废)。30 张证对应作废 6 笔订单(假设按户分笔且每户 5 张),保留另外 6 户的 30 张。
如果是 1 笔大订单,只能整体作废 60 张,粒度不够。这就是推荐"按户分笔"的关键原因之一。