文件
hyb-oa/docs/adr/adr-enterprise-card-control.md
T

3.5 KiB
原始文件 Blame 文件历史

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 仅记录内部建议与审计摘要,不触发任何真实拒付、冻结或外部清结算动作。