uniprop-manual/prop-acc/scenarios/adhoc-flow-a-renovation-bulk-pass.md

---
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流-前台购买装修出入证]] — 单户场景

## 异常分支

- 某户中途停工 → [[场景-已收款作废]] 作废对应那几笔
- 录入金额错误 → [[场景-已收款作废]] 重做