huang
1cf17e8f14
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 5m46s
- 移除 Model 层：删除 ShopSeriesCommissionTier 模型及相关字段 - 更新 DTO：删除 TierCommissionConfig、TierEntry 类型及相关请求/响应字段 - 删除 Store 层：移除 ShopSeriesCommissionTierStore 及相关查询逻辑 - 简化 Service 层：删除梯度返佣处理逻辑，统计查询移除 tier_bonus 字段 - 数据库迁移：创建 000034_remove_tier_commission 移除相关表和字段 - 更新测试：移除梯度返佣相关测试用例，更新集成测试 - OpenAPI 文档：删除梯度返佣相关 schema 和枚举值 - 归档变更：归档 remove-tier-commission-redundancy 到 archive/2026-01-30- - 同步规范：更新 4 个主 specs，标记废弃功能并添加迁移指引 原因：梯度返佣功能与一次性梯度佣金功能重复，且从未实现实际计算逻辑 迁移：使用一次性佣金的梯度模式 (OneTimeCommissionConfig.type = "tiered") 替代
5.2 KiB
5.2 KiB
ADDED Requirements
Requirement: 订单支付后触发佣金计算
系统 SHALL 在订单支付成功后自动触发佣金计算。计算通过异步任务执行。
Scenario: 支付成功触发计算
- WHEN 订单支付状态变为已支付
- THEN 系统发送佣金计算异步任务
Scenario: 重复支付不重复计算
- WHEN 订单已计算过佣金（commission_status=2）
- THEN 系统不重复触发计算
Requirement: 成本价差收入计算
系统 SHALL 为代理链上的每一级代理计算成本价差收入。终端销售代理收入 = 售价 - 成本价；中间层级代理收入 = 下级成本价 - 自己成本价。
Scenario: 单级代理
- WHEN 一级代理销售套餐，售价 100 元，成本价 80 元
- THEN 一级代理获得 20 元（100 - 80）成本价差收入
Scenario: 多级代理
- WHEN 三级代理销售套餐，售价 100 元，各级成本价为：平台 50 → 一级 60 → 二级 70 → 三级 80
- THEN 三级获得 20 元（100 - 80），二级获得 10 元（80 - 70），一级获得 10 元（70 - 60），平台获得 10 元（60 - 50）
Scenario: 成本价相同
- WHEN 某级代理成本价等于下级成本价
- THEN 该级代理成本价差收入为 0，不创建佣金记录
Requirement: 佣金直接入账
成本价差收入 SHALL 直接入账到店铺钱包，无冻结期。
Scenario: 佣金入账
- WHEN 计算出代理的成本价差收入
- THEN 系统直接增加店铺钱包余额，创建佣金记录和钱包交易记录
Scenario: 记录入账后余额
- WHEN 佣金入账
- THEN CommissionRecord.balance_after 记录入账后的钱包余额
Requirement: 更新累计充值金额
订单支付成功后系统 SHALL 更新卡/设备的累计充值金额。
关键修复：每次支付成功都必须写回累计充值金额，确保累计值能正确用于一次性佣金的累计触发判断。
Scenario: 单卡订单更新累计充值
- WHEN 单卡订单支付成功，金额 100 元
- THEN 系统读取 IotCard.accumulated_recharge 当前值
- AND 增加 10000 分（100 元 = 10000 分）
- AND 将新值写回 IotCard.accumulated_recharge
- AND 使用更新后的累计值判断是否触发一次性佣金
Scenario: 设备订单更新累计充值
- WHEN 设备订单支付成功，金额 300 元
- THEN 系统读取 Device.accumulated_recharge 当前值
- AND 增加 30000 分（300 元 = 30000 分）
- AND 将新值写回 Device.accumulated_recharge
- AND 使用更新后的累计值判断是否触发一次性佣金
Scenario: 累计充值更新使用原子操作
- WHEN 更新累计充值金额
- THEN 系统使用 SQL 原子操作（如
accumulated_recharge = accumulated_recharge + ?） - OR 使用 GORM 乐观锁（version 字段）
- AND 确保并发场景下累计值不会丢失
Scenario: 更新失败不影响佣金计算
- WHEN 累计充值金额更新失败（数据库错误、并发冲突等）
- THEN 系统记录错误日志
- AND 继续执行后续的佣金计算流程（成本价差、一次性佣金等）
- AND 不因累计值更新失败而导致整个佣金计算失败
Requirement: CommissionRecord 模型简化
系统 MUST 简化 CommissionRecord 模型，移除冻结相关字段。
Scenario: 新佣金记录字段
- WHEN 创建佣金记录
- THEN 包含：shop_id, order_id, iot_card_id, device_id, commission_source, amount, balance_after, status, released_at, remark
Scenario: 佣金来源类型
- WHEN 创建佣金记录
- THEN commission_source 为以下之一：cost_diff（成本价差）、one_time（一次性佣金）
Scenario: 不再支持梯度奖励来源
- WHEN 尝试创建 commission_source = "tier_bonus" 的佣金记录
- THEN 系统拒绝并返回错误 "不支持的佣金来源类型"
Requirement: 一次性佣金触发检查
系统 SHALL 在更新累计充值金额后立即检查是否触发一次性佣金。
Scenario: 累计达到阈值触发佣金
- WHEN 更新累计充值后，累计值 ≥ 配置阈值
- AND 卡/设备的 first_commission_paid = false
- THEN 系统发放一次性佣金
- AND 标记 first_commission_paid = true
Scenario: 累计未达到阈值不触发
- WHEN 更新累计充值后，累计值 < 配置阈值
- THEN 系统不发放一次性佣金
- AND first_commission_paid 保持不变
Scenario: 已发放过不重复触发
- WHEN 更新累计充值后，累计值 ≥ 配置阈值
- AND 卡/设备的 first_commission_paid = true
- THEN 系统不重复发放一次性佣金
Requirement: 累计充值更新日志记录
系统 SHOULD 记录累计充值金额的更新操作，便于问题排查。
Scenario: 记录更新前后的累计值
- WHEN 更新累计充值金额
- THEN 系统在日志中记录：订单 ID、资源类型（卡/设备）、资源 ID、更新前累计值、本次充值金额、更新后累计值
Scenario: 记录更新失败原因
- WHEN 累计充值金额更新失败
- THEN 系统在日志中记录：订单 ID、资源 ID、失败原因（错误信息）、重试次数（如适用）