break
ce24d5612e
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 9m20s
- 新增 6 张表与成对迁移 000212，扩展企业微信审批场景业务类型白名单 - 后台线下套餐订单与两条代理线下充值入账路径在来源成功事务内建账，来源唯一键幂等 - 核销申请、审批尝试记录、账单分摊预占与驳回重提，审批业务类型 employee_collection_approval - 企业微信终态消费幂等：通过转已核销、驳回释放预占、通过后撤销不回滚并转异常终态 - 退款成功事务内按 bill_id+refund_id 幂等冲销账单或仅写退款关联提示 - 线下收款方式字典、账单查询/统计/关闭、申请查询与代办权限，均写入事务内审计 OpenSpec Change: add-employee-collection-bills
33 lines
3.3 KiB
Markdown
33 lines
3.3 KiB
Markdown
## Why
|
||
|
||
平台代理或无代理归属的 C 端客户以线下方式购买套餐、或代理线下充值预存款时，实际经办后台账号形成公司应收欠款。当前系统只有订单或充值审批，无法将这笔欠款、客户外部付款凭证、企业微信核验和最终核销结果形成独立、可分摊且可审计的闭环。
|
||
|
||
本 Change 落实讨论稿 AUG26-001：只覆盖功能上线后的新增业务，不回填任何历史账单，避免把历史支付事实以推测方式写入新财务账。
|
||
|
||
## What Changes
|
||
|
||
- 新增员工代收款账单：后台线下套餐订单创建成功后，或代理线下预存款/主钱包充值完成入账后，按确定金额为实际经办账号创建唯一账单。线下充值以“平台账号发起的线下充值入账成功”这一既有事实为锚点，既有企业微信终审通过入账与既有线下充值人工确认入账均适用；建账只由来源成功事务触发，不扫描或补建历史记录。
|
||
- 新增核销申请和账单分摊：员工按一笔外部付款创建一张申请，可选择多张账单并填写各自分摊金额；同一账单可由多笔已通过申请分次核销。
|
||
- 新增固定分类的线下收款方式字典；申请冻结字典名称、外部付款、附件、账单分摊，每次提交或重提另存一条审批尝试记录。OCR 仅可预填流水号和付款金额，人工确认值才是业务事实。
|
||
- 核销申请仅由企业微信最终结果驱动（通过、驳回、通过后撤销）；提交失败、回调延迟或结果未知复用既有审批查询/恢复闭环，禁止本地人工绕过终审，通过后撤销不回滚已核销金额。
|
||
- 新增账单、核销申请、分摊、附件与审批记录的权限受控查询；超级管理员关闭未结清账单、来源订单退款时的账单冲销均保留审计。
|
||
- **BREAKING**：会生成员工账单的后台线下套餐订单不再在创建时强制上传付款凭证；凭证和外部付款信息改为核销申请必填。赠送套餐等不生成账单的既有线下订单继续保持原凭证要求。
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
- `employee-collection-bill`: 员工代收款账单、线下收款方式、分摊核销申请、企业微信审批闭环、退款冲销和受控查询。
|
||
|
||
### Modified Capabilities
|
||
|
||
- 无。本 Change 通过新能力监听并引用既有订单和代理充值的已确定业务事实，不重写其既有主规格。
|
||
|
||
## Impact
|
||
|
||
- 数据：新增账单、收款方式字典、核销申请、分摊、审批尝试记录和退款冲销关联等表；订单/充值来源只保存可追溯关联，不回填历史记录。
|
||
- 写侧：后台线下套餐下单、代理线下充值入账、核销提交/重提/关闭、企业微信审批结果消费、套餐退款。
|
||
- 读取：账单与申请列表、详情，以及与列表同筛选、同数据范围的统计聚合；欠款人仅看本人，超级管理员看全部；不新增导出。
|
||
- 配置：不新增任何运行时开关或配置来表达上线切割点；新表对既有旧代码无影响，单批发布即可。
|
||
- 权限：本期不引入“财务”角色，也不启用 `RequirePermission` 路由鉴权体系；财务独立可见性留待后续权限 Change。
|
||
- 依赖：复用既有企业微信通用审批实例、可靠提交和状态恢复机制；OCR 与外部付款渠道不在本 Change 新建契约。 |