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
154
prop-acc/scenarios/adhoc-flow-a-renovation-bulk-pass.md
Normal file
154
prop-acc/scenarios/adhoc-flow-a-renovation-bulk-pass.md
Normal file
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: prop-acc · 场景 - A 流 - 装修公司批量采购出入证
|
||||
aliases:
|
||||
- 场景 - A 流 - 装修公司批量采购出入证
|
||||
- 场景-A流-装修公司批量采购出入证
|
||||
tags:
|
||||
- 场景
|
||||
- prop-acc
|
||||
- 一次性收费
|
||||
- 业务场景
|
||||
- A流
|
||||
audience:
|
||||
- 业务人员
|
||||
status: 已发布
|
||||
last_review: 2026-05-25
|
||||
code_version: 2026-05-22
|
||||
---
|
||||
|
||||
# 场景:装修公司批量采购出入证
|
||||
|
||||
**与个人业户买装修证不同**:大型装修公司同时承包小区里几十户装修,每户都要发出入证 —— 一次买 50-200 张的场景。
|
||||
|
||||
> [!info] 主要给业务人员看
|
||||
> 这个场景对业户(装修公司联系人)而言是"批量买 + 一笔结清";对业务人员是"录入快、对账难"。
|
||||
|
||||
## 典型情境
|
||||
|
||||
> [!example] 真实情境
|
||||
> 鸿基装修公司在小区里承包 12 户精装修业务,共需要 60 张出入证。公司财务下午到物业,要一次性办完 60 张 + 一张发票。
|
||||
|
||||
## 业户(装修公司联系人)视角
|
||||
|
||||
### 您要准备什么
|
||||
|
||||
| 材料 | 数量 |
|
||||
|---|---|
|
||||
| 公司营业执照复印件 | 1 份 |
|
||||
| 法人 / 经办人身份证 | 1 份 |
|
||||
| **每户的装修合同**(原件 + 复印件)| 12 份 |
|
||||
| 60 个工人的身份证复印件 | 60 份 |
|
||||
| **可开发票的公司抬头 / 税号** | 用于开发票 |
|
||||
|
||||
### 流程
|
||||
|
||||
1. 到物业前台,出示材料
|
||||
2. 物业核对身份和合同
|
||||
3. 物业算总价:60 张 × ¥30 = ¥1800
|
||||
4. 您付款(**通常公司账户转账或 POS 公司卡**)
|
||||
5. 拿到 60 张装修证 + 发票(发票流程独立)
|
||||
6. 把 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`,**得先建一个"客户档案"再下订单**。
|
||||
|
||||
## 系统流程
|
||||
|
||||
```mermaid
|
||||
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 天,可以折中:
|
||||
> 1. 当天先录 Pending(用 B 流的 `CreatePendingAdHocEventAction`)
|
||||
> 2. 到账日再批量翻 Completed
|
||||
|
||||
> [!question] 业户要求开**一张大发票** 还是 **12 张小发票**?
|
||||
> 发票流程独立于订单,系统不强制对应关系。多数公司要一张大发票(便于报销),物业方按业户需求开即可。
|
||||
|
||||
> [!question] 60 张证录 12 笔太慢了,有批量录入吗?
|
||||
> 当前 Filament 后台**没有批量录入入口**。如果业务上批量场景很多,可以考虑加一个"批量下单" Filament Action(类似 ImportMeterReadingsAction 的导入模式)。**等业务方反馈再做**。
|
||||
|
||||
> [!question] 装修公司中途停工(只用了 30 张证)能退一半吗?
|
||||
> 技术上每笔订单可以**单独作废**(详见 [[场景-已收款作废]])。30 张证对应作废 6 笔订单(假设按户分笔且每户 5 张),保留另外 6 户的 30 张。
|
||||
>
|
||||
> 如果是 1 笔大订单,**只能整体作废 60 张**,粒度不够。这就是推荐"按户分笔"的关键原因之一。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[概念-A流与B流]]
|
||||
- [[概念-CollectionOrder与Receipt]]
|
||||
- [[场景-A流-前台购买装修出入证]] — 单户场景
|
||||
|
||||
## 异常分支
|
||||
|
||||
- 某户中途停工 → [[场景-已收款作废]] 作废对应那几笔
|
||||
- 录入金额错误 → [[场景-已收款作废]] 重做
|
||||
Reference in New Issue
Block a user