68 行
3.5 KiB
Markdown
68 行
3.5 KiB
Markdown
# ADR: 企业卡/虚拟卡管控能力预研
|
||
|
||
- **状态**: Accepted (PoC 完成)
|
||
- **日期**: 2026-02-10
|
||
- **关联 Issue**: S1
|
||
|
||
## 背景
|
||
当前报销流程为“事后报销”。随着费用规模增长，管理层希望评估“企业卡/虚拟卡”是否值得投入，以降低垫资与票据补录成本，并与预算控制联动。
|
||
|
||
## 决策目标
|
||
1. 明确能力边界（做什么/不做什么）。
|
||
2. 给出最小可实施数据模型草案。
|
||
3. 评估与预算控制联动价值与 ROI。
|
||
4. 提供可回滚路径。
|
||
|
||
## 方案对比
|
||
### 方案 A：不做企业卡，持续优化现有报销
|
||
- 优点：实现成本最低，不引入支付清结算风险。
|
||
- 缺点：员工垫资与票据补录问题长期存在。
|
||
|
||
### 方案 B：只做“虚拟卡授权 + 交易对账导入”（推荐）
|
||
- 优点：
|
||
- 可在现有 `integration_outbox` + `travel_orders` 机制上增量扩展。
|
||
- 与预算池可形成“事前授权 + 事后核销”闭环。
|
||
- 不直接改造核心审批状态机，风险可控。
|
||
- 缺点：需要第三方支付/发卡通道，需处理对账延迟与异常交易。
|
||
|
||
### 方案 C：自建完整企业卡账务系统
|
||
- 优点：掌控力最强。
|
||
- 缺点：投入和合规成本过高，不符合当前阶段。
|
||
|
||
## PoC 结论
|
||
- 使用 mock 交易流水模型验证：
|
||
- 交易导入 -> 预算池扣减 -> 报销关联核销 可形成闭环。
|
||
- 交易失败/重复导入可通过幂等键控制。
|
||
- 关键风险：
|
||
- 外部支付通道 SLA 不稳定；
|
||
- 对账日切与本地时区差异；
|
||
- 退款/撤销的反向台账一致性。
|
||
|
||
## 推荐落地范围（P8+）
|
||
1. 新增 `card_transactions`（最小字段：external_txn_id、employee_id、amount、currency、occurred_at、status、raw_payload）。
|
||
2. 新增 `card_authorizations`（预算池授权额度快照）。
|
||
3. 与预算台账联动：
|
||
- 授权占用 `kind=authorize`
|
||
- 核销 `kind=settle`
|
||
- 撤销 `kind=reverse`
|
||
4. 不在首期引入自动拒付策略，仅做预警与冻结建议。
|
||
|
||
## ROI 粗评估
|
||
- 假设月均 3000 笔差旅相关支出：
|
||
- 票据补录和对账人工可减少约 30%~45%。
|
||
- 财务月结周期可缩短约 1~2 天。
|
||
- 若企业卡通道费率高于节省人工成本，建议暂缓。
|
||
|
||
## 回滚策略
|
||
1. 关闭企业卡开关（保留历史数据）。
|
||
2. 停止交易导入任务与对外同步。
|
||
3. 预算恢复到“报销提交时校验”模式。
|
||
4. 历史交易只读归档，不做数据删除。
|
||
|
||
## TRAVEL-2 实施化决议（2026-03-10）
|
||
- 在保留本 ADR 原有“企业卡授权 + 交易导入”为主轴的前提下，`P20+TRAVEL-2` 正式采用**混合双轨**：`CardAuthorization / CardTransaction` 承载内部支付账轨，同时新增 `POST /api/travel-orders/:id/mark-paid` 作为运营结算入口。
|
||
- 发票绑定采取最小增量实现：仅在 `invoice_pool` 新增 `travel_order_id`，继续复用现有发票池绑定入口；不在本期把发票绑定抽象重构为全域多态模型。
|
||
- ERP payment journal 前移到 `TRAVEL-2`：`travel_order.paid` 会直接复用 `erp.journal.export` 出站 `travel_order_payment` journal，但 AP 摘要、核销批次、requeue / dead-letter 运营能力仍明确留在 `TRAVEL-3`。
|
||
- 预算语义固定双账轨并存：`travel_request` 继续保留 `reserve / confirm / release` 申请预算；企业卡/支付轨道单独使用 `authorize / settle / reverse`，两条账轨互不回写。
|
||
- `freeze-suggestion` 仅记录内部建议与审计摘要，不触发任何真实拒付、冻结或外部清结算动作。
|