break
ba0855d9eb
按 PRD 2.3/2.4/2.5 落地套餐退款的方式矩阵与原路渠道退款： - 退款申请派生并冻结权威实收金额（线上取原成功支付记录，钱包/线下取订单实际收款）， 提交人不可填写或修改；按来源支付方式生成可选方式矩阵并在创建、提交、执行前重复校验。 - 审批切换为「每次提交一条不可变审批尝试记录 + 独立企业微信审批实例」，业务标识取尝试 记录主键；终态消费按尝试记录优先、退款申请兜底双读，兼容存量无实例与已关联实例申请。 新增活动退款部分唯一索引 (order_id) WHERE status IN (1,5,6)。 - 本地人工终审保持既有开关，补齐通过入口的 approval_instance_id IS NULL 守卫，使三个 入口一致拒绝已关联审批实例的申请；重提按尝试模式重写（仅已拒绝/已退回/原路失败且无异常）。 - 权益时点：企微通过事务写退款终态、按方式确定的订单态、钱包回款、员工账单冲销与可靠 失效事实；套餐失效/接续/停机仍由既有可靠机制最终一致执行，不把外部调用放入资金事务。 订单支付状态按方式置位：凭证退款与退回原钱包在企微通过时置已退款，原路须渠道明确成功。 - 按官方契约实现微信直连 v3、微信 v2（双向证书）、富友（/commonRefund 与 /refundQuery）、 支付宝四类原路退款；能力只由服务商类型与退款必需凭证完整性决定，无人工开关。 渠道请求号在提交时冻结到尝试记录，并以 channel_submitted_at 条件认领保证资金动作至多 提交一次（重复投递只查询不二次提交）；不向任何渠道传递退款结果通知地址。 - 新增 refund:channel:recovery 恢复任务只查询回填；本地查询窗口超期（富友 72 小时、 微信 v2 7 天）转原路退款失败、渠道状态已失败、分类超时未知并置异常转人工，不放行自动 重提以避免重复退款。 - 同步退款 DTO/导出/审计资源与审计查询关联、商户凭证文档，并修正 fuiou 集成契约文档。 迁移 000218（退款尝试与渠道退款事实）、000219（微信 v2 客户端证书凭证）成对提供， 未修改既有迁移；测试库 junhong_cmp_test 完成 up/down/up 与行为核对，未调用真实渠道。
2.4 KiB
2.4 KiB
Scope
- 迭代编号：
AUG26-006。
Why
现有退款以本地审批状态处理，不能按来源实际支付事实决定退款方式、冻结实收金额，或在企业微信通过后用原实际收款商户可靠执行原路退款；退款单也无法按「每次提交持有独立审批实例」重提，且系统没有任何渠道原路退款调用。
What Changes
- 退款申请冻结来源订单、权威实收金额、唯一套餐使用情况、退款金额/原因、方式和当次审批材料；实收金额由系统从原成功支付记录或订单实际收款派生，提交人不可填写或修改。
- 建立线上支付、资产钱包、代理主钱包和后台线下订单的退款方式矩阵，并在创建、提交和执行前重复校验。
- 企业微信是唯一审批终审；每次提交或重提新增一条不可变审批尝试记录与一个新的企业微信审批实例，历史材料不被覆盖；本地人工终审只保留既有存量终结路径，不新增任何运行时开关。
- 企业微信通过即写可靠失效事实，使关联套餐失效、接续下一套餐并评估停机，由既有可靠机制最终一致执行；客户收款信息退款与退回原钱包在企微通过时完成，原路退款须待渠道明确成功才完成，且仅此时置订单已退款。
- 按官方契约新增微信直连、富友和支付宝的原路退款适配，固定使用原支付单实际商户与其当前凭证；渠道能力只由服务商类型与退款必需凭证完整性决定，不提供人工开关；超时/未知/失败保留可恢复状态，不重复退款。
- 一笔订单最多一张最终成功退款、同时至多一张活动退款申请，由活动退款唯一约束与条件状态更新共同保证。
Capabilities
New Capabilities
- 无。
Modified Capabilities
order-refund-exchange: 退款申请、状态机、方式矩阵、原路渠道退款执行与套餐联动。
Impact
影响退款模型/接口、企业微信审批、支付商户与渠道退款（微信直连、富友、支付宝）、资产/代理钱包、员工账单和佣金回溯；需新增成对迁移。
渠道适配按官方 SDK/接口契约实现，本 Change 不调用任何真实支付渠道验证：本地验证使用受控适配器桩，「未做外部渠道实测」只作记录，不作为阻塞、未完成任务或上线前置，真实渠道可退款性由维护者后续手工验证。