商品 · 订单 · 退款交易中心优化改造

1退款渠道模型与状态机

refundType 渠道枚举

渠道在 apply() 阶段由原订单 payType 决定，不是用户随意选；权益扣减也在 apply() 阶段（refundMemCardOrder/refundPrivate）完成，因此 audit/pay 仅做状态流转——这正是 refundType=4 只需「审核即完成」的根本原因。

status 状态机

2RefundDrawer 主动退款抽屉前端

src/views/order/components/RefundDrawer.vue（约 800 行，新建/重构）— 从 order/member.vue & course.vue 的「退款」按钮唤起，渠道优先流。

• 4 个渠道卡片：tuangou / original / offline / tgPlatform（仅 hasTuangou 时显示后两个团购相关）
• 撤销核销倒计时：全局单一 setInterval + tickerSubs 多实例订阅，美团 10min / 抖音 60min 窗口，过期 disabled
• 残值计算器：residualValue → recommendedRefundable → cappedRecommended 全 computed 链路
• 共享样式 src/styles/refund-drawer.scss（非 scoped，drawer 用 custom-class 命中）
• 抽屉宽度 720→880px（内容承载）；buildPayload 目前 $emit('submit') mock，待接后端

3可退金额计算 + 两个关键实现点前端

计算链路

// 残值：课时卡按比例；无单位数据兜底为剩余可退（要点②）
residualValue   = !totalUnits ? remainingPayable
                              : round2(paidAmount * remainUnits / totalUnits)
recommendedRefundable = max(0, residualValue - penaltyFee - discountSupplement)
maxRefund       = mode==='tuangou' ? paidAmount : min(channelMax, remainingPayable)
cappedRecommended     = min(recommendedRefundable, maxRefund)
// 财务打款上限 = 最终实收（要点①）
finalReceived   = round2(max(0, paidAmount - alreadyRefunded) * (1 - feeRate))
                  feeRate = hasTuangou ? 0.08 : 0.006

要点 ① 财务打款上限 = 最终实收

channelMax() 的 offline 分支取 finalReceived（最终实收），label 为「最终实收（通道/平台扣费后）」，渠道卡副标题与上限提示按费率口径说明。与订单列表 computeFinalReceived 口径一致（团购 8% / 通道 0.6%）。

要点 ② 可退金额自动联动（computed 驱动）

// 重构：computed 驱动取代 watch/nextTick
isManualRefundable() { return this.manualRefundable !== null }
effectiveRefundable: {
  get() { return manualRefundable != null ? manualRefundable : cappedRecommended },
  set(v){ const n=num(v); manualRefundable = |n-cappedRecommended|<0.001 ? null : n }
}
// 兜底：无单位数据 → 残值 = 剩余可退（实付−已退），而非 0
residualValue(){ if(!totalUnits) return this.remainingPayable; ... }

同步删除 syncRefundable/onRefundableChange/resetRefundable 方法、form.penaltyFee/discountSupplement 两个 watch、未用的 hasSettleAmount；applyModeDefaults/reset 改为只置 manualRefundable=null。

4退款单审批流改造（跳过财务）前端后端

src/views/finance/refundList.vue（约 1448 行，合并自 origin/Release260309 后重构）+ 后端 RefundBusiness.java。

后端 RefundBusiness.java（未提交）

audit(): autoPayout = refundType==1 || refundType==2 || refundType==4
        → 命中则 audit 内串接 pay()，status 直推 3
        → refundType==4 成功文案「审核通过，已标记团购平台原路退款」
pay() : 新增 else-if payType==4 分支 —— 纯标记：
        setRefundType(4)/setStatus(3)/setStatusName("打款完成")/setPayTime
        不走通道、不动 tuangou_order

前端 refundList.vue

• 筛选项 compact 化、合并列、操作按钮整齐化；移除「新增退款单」入口
• 4 渠道卡片 + modeKey 增加 4:'tgPlatform'；channel-pill ch-4 绿色
• audit 按钮 / summary / confirm / success 文案均加 refundType=4 分支
• 用户取消(status=-2) / 运营驳回(status=-1)：渠道 chip 弱化 + title「未实际走通道」
• mounted 接受 ?refnum= / ?orderNumber= query 直达

5refundType=4 团购平台原路退款本次新增

业务语义：用户已在美团/抖音 App 自助退款且到账，本系统仅做登记标记 + 权益扣减，不发起任何实际退款。仅对团购订单（hasTuangou）开放。

6商品 ↔ 团购 一对多映射重构前端

团购订单核销/发权益、退款撤销核销恢复券、refundType=4 扣权益，全部依赖「内部商品 ↔ 团购套餐」绑定关系。本次将该能力从旧 groupCoupon/bingCoupon.vue 等分散入口，重构进 member/config.vue（门店配卡页）。

数据模型（一对多约束）

// 内部商品(会员卡 cardId / 私教课 courseId) 1 ── N 团购绑定
binding = { channel:1美团点评|2抖音, dealId, dealGroupId,
            procuctType:1会员卡|2私教课, procuctId, procuctName }
// 反向唯一：一个 dealId 只能绑一个内部商品 → boundDealInfo(dealId) 命中即提示「已绑定到 XX」

7订单列表 / 详情抽屉重构前端

8后端改动清单（lianer-back，未提交）后端

9风险点 / 待接入 / 评审关注

• RefundDrawer.buildPayload 仍是 mock（$emit('submit') + message），主动退款发起接口待接入，需后端确认入参契约（mode/refundAmount/penaltyFee/discountSupplement/manualOverride…）。
• 费率硬编码 团购 8% / 通道 0.6% 前端写死，最终实收/财务上限均依赖之；建议后端下发或常量集中管理。
• 残值兜底 无单位数据时残值=剩余可退，对年卡可能偏高；是否需要后端补 used/surplus 字段或人工复核口径待定。
• refundType 判定 由原订单 payType 推导，需回归核对各支付方式映射（尤其团购窗口期 美团10/抖音60min）。
• 后端未提交 上线前需确认 RefundBusiness 改动的回归范围（audit 串接 pay 对存量 type=1/2 单据的影响）。
• 权益扣减时机 在 apply() 阶段；refundType=4 审核即完成依赖此前提，评审需确认补登场景下 apply() 一定已扣权益。
• 团购绑定反向唯一 dealId 唯一性目前靠前端 boundDealInfo 提示，需后端在 tunagouBindProduct 做唯一约束兜底，否则并发/绕过前端会产生一 deal 多商品脏数据，核销发错权益。
• 解绑与存量核销单 deleteTuangouProduct 解绑后，已核销未发权益的存量团购单如何归属待定，建议解绑前校验。
• 分支 V0510 diff 含较多非本域基线差异（member/coach 等），评审请聚焦 order/finance/refund 相关文件。