3.9 KiB
Context
退款申请由后台提交业务资料，审批过程在企微完成，后台只负责展示企微审批信息以及订单退款的业务处理结果。当前页面仍按本地审批模型展示通过、拒绝和退回操作，需要调整为只读状态展示并保留受限的重新申请能力。
Goals / Non-Goals
- Goals: 让退款创建、列表和详情与企微审批及业务处理状态保持一致。
- Goals: 展示可追溯的审批单号、参与人、意见、附件和时间线。
- Goals: 明确区分审批状态与业务处理状态，并覆盖处理失败和自动重试提示。
- Goals: 允许符合条件的退款重新申请，同时锁定订单、资产和提交人快照。
- Non-Goals: 不在前端实现企微审批动作、审批回调或审批引擎。
- Non-Goals: 不在后台执行非代理钱包的人工退款。
- Non-Goals: 不根据本地旧状态推断企微审批状态或处理状态。
Decisions
-
Decision: 详情接口返回的
approval对象作为企微审批信息的唯一数据源。 -
Rationale: 审批动作在企微完成，前端不应通过本地状态或额外请求重建审批过程。
-
Decision:
processing_status与审批状态独立展示，并使用后端返回的状态名称、失败摘要和业务处理结果。 -
Rationale: “审批通过”不等于退款处理完成，两个状态必须避免混用。
-
Decision: 创建和重新申请的附件统一使用
{ file_key, file_name, file_size }[]。 -
Rationale: 页面既要提交对象存储文件标识，也要在审批详情中保留可读的文件元数据。
-
Decision: 重新申请资格由后端最终校验，前端按已驳回、已撤销或已删除状态控制入口并处理接口拒绝。
-
Rationale: 状态可能被并发更新，前端展示控制不能替代服务端业务校验。
-
Decision: 移除本地通过、驳回、退回和人工退款确认入口及调用。
-
Rationale: 这些操作与企微审批职责冲突，继续保留会造成重复审批或错误退款。
Data Contract
- Create request: refund amount, reason, remark and
attachments. - Detail response: refund business data,
approvalobject andprocessing_status. - Approval object:
source,sp_no,status,status_name,template_version,applicant,approvers,comments,attachments,timeline,business_process_result. - Resubmit request: editable refund amount, attachments and reason; immutable order, asset and submitter snapshots.
- Resubmit eligible statuses: rejected, revoked or deleted, using the backend status contract.
Risks / Trade-offs
-
Risk: 企微审批状态名称或时间线字段可能为空或增加新状态.
-
Mitigation: 保留后端原始字段，缺失时显示稳定占位，不在前端硬编码未知状态映射。
-
Risk: 审批通过后业务处理可能失败或进入重试.
-
Mitigation: 独立展示处理状态、失败摘要，并按后端结果显示系统重试或联系管理员提示。
-
Risk: 后端仍允许旧本地审批接口调用.
-
Mitigation: 前端移除入口和调用，同时由后端按新审批模式拒绝不适用的本地操作。
Migration Plan
- 确认退款创建、详情和重新申请接口的字段名称及状态枚举。
- 扩展退款类型和对象存储附件元数据类型。
- 更新创建退款表单和附件提交结构。
- 重构退款详情为业务信息、企微审批信息和业务处理结果三个区域。
- 移除本地审批及人工退款操作，保留并限制重新申请入口。
- 验证审批中、通过处理中、处理成功、驳回、撤销和通过后撤销异常状态。
Open Questions
processing_status的完整枚举、展示名称和“系统重试中/联系管理员”的触发字段需要后端确认。- “已删除”是退款记录状态、审批状态还是业务处理状态，需要接口契约明确。
approval.attachments是否与退款创建附件共用文件对象结构，需要联调确认。