junhong_cmp_fiber/docs/7月迭代/七月迭代需求范围确认表.md

# 七月迭代需求范围确认表

> 用途：由需求负责人逐条确认本期是否实施、按什么口径实施，以及哪些内容明确后置或取消。
>
> 来源：`docs/7月迭代/物联网卡管系统-需求.csv` 当前 41 条记录。其中 36 条挂在七月迭代计划，5 条已关闭。
>
> 填写完成后，请通知后端重新审查。本表确认前，不据此修改 `complete-july-iteration-test-release` 或实施业务代码。

## 填写说明

每条需求只勾选一个“本期决定”，然后在“说明”中补充你的处理意见即可。

本期决定：

- [ ] 本期做：本次迭代必须上线。
- [ ] 已完成，只联调/验收：不再重复开发后端。
- [ ] 后置：需求保留，但不阻塞本次上线。
- [ ] 不做：取消或移出当前产品范围。
- [ ] 待确认：产品口径仍不清楚，暂不实施。

填写示例：

```markdown
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：只在现有店铺列表增加联系电话精确筛选。
```

---

## 一、新增、漏项或未被当前提案准确追踪的需求

### #189 换货迁移套餐退款后未正常失效

- 原始需求：换货后的新卡继承旧卡套餐后，对原订单退款，退款通过但套餐没有正常失效。
- 当前判断：提案漏项；属于退款与换货交叉缺陷。
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：跟前端没关系；这个问题是后端查找路径有问题，按 Bug 修复即可。

### #188 广电管控卡弹窗提醒

- 原始需求：广电风险停机卡在 H5 弹窗提醒换卡并采集收货地址；描述中还包含后台主动投放、自定义营销内容、自动换货单和 ERP 对接设想。
- 当前判断：提案漏项；“风险卡提醒”与“通用营销投放/ERP”应分别确认。
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：他描述的有远,我们只在已经完成的站内通知的基础上,保证创建物流换货单的时候会在C端弹窗通知用户

### #182 退款和代理充值列表增加提交人

- 原始需求：退款管理和订单/代理充值后台列表增加提交人字段。
- 当前判断：与 #44 部分重复；可先作为简单字段独立交付，不应等待完整企微审批体系。
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：现在数据库里面存了提交人的ID,在列表跟详情中返回id跟名称就好了

### #181 订单和退款列表缺少资产标识、订单渠道

- 原始需求：设备类订单、退款记录未正确展示资产标识符和订单渠道。
- 当前判断：提案漏项；属于 DTO/查询/展示字段修复。
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [  ] 不做
- [ ] 待确认

- 说明：这算是一个bug,我记得只有C端购买订单的时候会缺少订单渠道,然后退款列表跟退款详情是设备的标识没有正确放入

### #99 退款支持原路退回

- 原始需求：支持原路退款和客户收款凭证退款；原路退款前校验原收款商户退款能力，失败后允许改为凭证退款。
- 当前判断：提案漏项，并与现提案“部分支付方式系统外退款”口径冲突；属于资金业务，需明确真实范围。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：

### #84 H5 首页隐藏设备下 ICCID

- 原始需求：新卡管 H5 首页不再显示设备号下方的 ICCID。
- 当前判断：提案漏项；基本属于纯前端调整。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：跟我们后端没关系

### #52 聚水潭对接

- 原始需求：打通聚水潭订单、发货等数据。
- 当前判断：提案漏项；当前没有接口清单、数据方向和验收标准，不能直接实施。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：现在不做

### #51 不同品类资产换货及补差价

- 原始需求：卡与设备跨品类换货、补差价、旧套餐失效、新资产使用正确品类套餐。
- 当前判断：当前为草稿，旧规划排除；属于独立复杂业务，不适合顺带实现。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：

### #41 代理 API 查询限制

- 原始需求名称存在误导，最终业务口径不是“代理跨级 API 查询限制”。
- 最终口径：为每个店铺提供一个 C 端登录限制开关；开关开启后，该店铺名下的卡和设备不能再发起新的系统 C 端登录。
- 建议最小范围：店铺增加配置字段并提供管理员配置入口；C 端资产校验成功后、签发短期资产令牌前按资产所属店铺校验。平台库存或未归属店铺的资产保持原行为。
- 明确不做：不重构代理权限体系，不做全局 Token 吊销，不强制已登录用户立即下线，不迁移现有认证模块。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：提供接口针对某个店铺开关；打开后，属于该店铺的资产不能登录系统 C 端。

### #39 代理分销码与佣金提现

- 原始需求：分销归属、分销码、佣金提现及合同/证照/发票材料。
- 当前判断：现提案明确移出本期；其中“员工作为发展人”已由 #96 单独承接。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：

---

## 二、已有后端成果，优先确认前端联调和验收

### #45 换货列表新旧资产展示和独立搜索

- 原始需求：修正新旧资产标识混乱；新旧资产分别支持 ICCID、接入号、虚拟号搜索。
- 当前判断：后端已完成且有测试，主要剩前端和人工验收。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：现在跟我们后端没关系了

### #46 资产预计套餐到期时间

- 原始需求：显示当前生效套餐过期时间，剩余 15 天时高亮。
- 当前实现：后端已实现“当前套餐加排队套餐后的预计最终到期时间”，且有测试。
- 需要确认：接受当前“预计最终到期”口径，还是改回只显示当前生效套餐到期时间。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：现在这个口径是对的,已经跟我们后端没有关系了,接口已经提供给前端

### #55 套餐分配生效条件

- 原始需求：套餐支持购买即生效或实名即生效，分配时可覆盖条件。
- 当前判断：后端已完成且有测试。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：已经提供给前端对接了,跟我们没关系了

### #60 店铺联系电话搜索

- 原始需求：店铺列表增加联系电话检索。
- 当前判断：后端已沿用旧 Store 完成精确查询并有测试，符合简单需求处理方式。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：已经提供给前端接口,跟后端没有关系了

### #73 行业卡允许未实名复机

- 原始需求：行业卡允许未实名复机。
- 当前实现：旧代码已经按 `card_category=industry` 放行未实名复机。
- 提案偏差：现提案准备改成按运营商 `realname_link_type` 判断，可能反向改变原需求。
本期决定（单选）：

- [ ] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [X] 不做
- [ ] 待确认

- 说明：先不管这个,只要行业卡能正确的不管有没有实名都能复机即可

### #86 资产详情换货标识与跳转

- 原始需求：详情显示新资产/旧资产换货标识，旧资产可链接新资产。
- 当前判断：后端已完成且有测试，主要剩前端和历史数据人工抽样。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：前端已经对接,现在与后端无关

### #38 代理信用额度

- 原始需求：代理可授权额度、不同额度下限、金额业务使用额度、允许显示负余额。
- 当前判断：后端代码基本完成，但资金链自动化和真实验证延期。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：接口已经提供给前端,具体测试是测试环节的事情,现在与后端无关吧,最好确认一下代码是否完成

### #94 状态同步优化和运营商回调

- 原始需求：因资产迁移优化状态同步和回调，原描述没有具体验收标准。
- 当前判断：后端已完成大范围公共观测和四类运营商回调，但真实运营商/Gateway 验证延期。
本期决定（单选）：

- [ ] 本期做
- [x] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明： 现在就算优化完了,有运营商回调,有时间触发,轮询还是保持老样子

### #96 店铺业务员/发展人

- 原始需求：新建店铺可选业务员，列表/详情展示，可按业务员筛选。
- 当前判断：后端代码完成，主要剩前端和验证。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：接口已经提供给前端了,与后端无关

### #98 换货新资产继承旧店铺

- 原始需求：换货时新资产默认继承旧资产归属。
- 当前判断：旧换货 Service 已实现主要归属继承逻辑；提案任务状态滞后，不应再建新的 Domain/分配记录。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这算做完了,就不要动了,到时候我会统一说创建一个新的提案,把原来的提案废掉

### #43 代理系列套餐批量授权

- 原始需求：支持一次多选，展示建议售价和公司成本价，区分已分配/未分配套餐。
- 当前判断：核心批量授权、价格和移除兼容能力基本已有；应轻量收口，不从头重构。
本期决定（单选）：

- [ ] 本期做
- [X] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这他妈就是错误的描述,之前我们的接口本身就支持批量多选,但是前端没做,这个需求跟后端没关系

---

## 三、适合沿用现有代码做局部修改的需求

### #53 卡和设备实名状态筛选

- 原始需求：卡管理、设备管理增加已实名/未实名筛选。
- 提案问题：增加设备实名投影、历史初始化、事件消费者和 Worker，明显超出简单筛选需求。
- 建议最小范围：优先在现有列表 DTO、Store 查询和返回字段上补筛选；只有现有数据无法准确查询时再讨论快照。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：设备有一个情况是,只要有任意一张卡实名了,就算实名

### #57 存在退款申请时禁止换货

- 原始需求：资产存在未完成退款申请时禁止换货，并提示“该资产存在退款申请”。
- 提案问题：被绑定到尚未完成的全新退款模型和企微审批链。
- 建议最小范围：在现有换货创建入口查询现有退款状态并拦截。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：没有什么特别注意的,越简单达成需求越好

### #62 H5 先充值/先实名流程配置

- 原始需求：进入 H5 先绑定手机号，并可按资产批次选择先充值后实名或先实名后充值。
- 当前判断：已有 `realname_policy`、单资产修改接口和 C 端购买/充值门禁，不应按从零 DDD 建设。
本期决定（单选）：

- [x] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明： 这个有点奇怪,之前我跟前端的约定是这样的"目标：支持无需实名、先实名后购买、先购买后实名三种流程，并提供后台批量配置。

预计工时：前端2～3小时。

页面入口：C端资产初始化流程；后台卡列表和设备列表。

页面结构：

1. C端按 effective_realname_policy 决定直接购买、先实名或购买后提示实名。

2. 后台卡和设备列表分别增加“批量修改实名顺序”入口。

3. 弹框提供无需实名、先实名后购买、先购买后实名三选一，并展示已选数量。

4. 修改设备下卡策略时提示“实际H5流程由设备策略决定”。

接口约定：

- PATCH /api/admin/assets/{identifier}/realname-mode，入参 realname_policy:none|before_order|after_order。

- POST /api/admin/iot-cards/batch-update-realname-policy、POST /api/admin/devices/batch-update-realname-policy，入参 asset_ids:int64[]、realname_policy:string。

- C端初始化返回 effective_realname_policy:string、realname_required:bool、realname_status:int。

交互规则：单次最多500条；批量接口全成全败；前端不根据资产类型自行覆盖策略。

完成标准：三种C端流程和卡/设备批量配置均可运行，冲突数据能展示明确错误。"

### #44 退款、充值、换货列表字段

- 原始需求：退款列表增加提交人/审批人；代理充值列表增加提交人/审批人；换货列表增加提交人。
- 提案问题：将简单字段绑定到通用审批、企微节点、历史回填和新状态模型。
- 建议最小范围：先交付已有数据能够提供的提交人/审批人字段；企微详情和历史快照另行确认。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个很关键,提交人我们现在就按照现在的有,只是存了id没有存名称,相关接口也没有返回,至于审批人,我们没办法拿到,这是企微模版中已经做好的,所以不用加审批人,或者说如果我们能通过模版拿到审批人企微的id,同时又跟我们系统的账号绑定了的话,就能正常展示审批人,这个看怎么搞,反正不能搞复杂了,我觉得就是一个很简单的,现有的逻辑都有了,只是把审批通过从我们系统中变成到企微中

### #97 代理钱包余额预警

- 原始需求：不同代理可配置不同预警额度，达到阈值时提醒代理及其发展人。
- 提案偏差：被改成固定 100 元且不提供阈值配置。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个主要是发站内通知,站内通知的功能好像已经做完了,这个就是低于100元的时候提醒发展人(业务员,创建店铺的时候选择的)

---

## 四、确有复杂业务，但需要重新确认原始口径

### #33 套餐临期提醒

- 原始需求：每日计算；15/7/3 天节点；企业客户企微推送业务员；代理端数量/高亮/置顶；C 端续费提醒。
- 提案偏差：企业微信提醒被排除，只保留站内通知。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个得做,我们只做站内提醒,还有代理端数量/高亮/置顶(我记得现在好像是单独开一个临期列表吧,后台管理跟代理端都要),然后C端那边的话就是这几个时间点站内通知弹窗提醒

### #34 代理在线充值与员工线下代充值

- 原始需求：代理提交充值后扫码支付；员工线下代充值走部门领导、财务审批并通知结果。
- 当前判断：业务未完成；在线支付、资金入账和线下审批应分别确认。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：在线充值可以后置,员工线下代充这个其实就是走企微审批,现在我记得是做了我们系统的审批,不知道怎么做的,好像是做成灵活的,未来可以接任何第三方的,现在不要考虑那么多了,先赶紧按照企微的审批做完再说别的

### #35 退款审核

- 原始需求：员工申请，部门领导和财务顺序审批，逐环节企微提醒，通过/驳回通知申请人。
- 当前判断：业务未完成；与 #37 共用审批能力，不应建立第二套审批系统。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个其实也是企微审批,退款本身我们已经做了,我记得退款好像本身也有审批吧,只是说我们让前端做成权限的了,谁能看见谁就能通过来着,现在就是把企微审批接进来

### #36 批量订购套餐

- 原始需求：内部员工上传 Excel；文件含资产类型、资产标识、套餐系列、套餐、代理、支付账户；校验后扣款订购并展示失败明细。
- 提案偏差：改成单列 CSV，不选择代理，整批只选一个套餐和支付方式。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个"改成单列 CSV，不选择代理，整批只选一个套餐和支付方式。"是对的

### #37 企业微信审核流转

- 原始需求：充值和退款多级审批、待办提醒、逐环节通知、结果通知，并接入企业微信。
- 当前判断：只完成渠道无关审批核心，企业微信 Adapter、绑定、模板、回调和轮询均未完成。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：是的剩下的东西都要完成。企微审批模板由管理员在企微后台创建，系统只配置“业务场景与企微模板”的绑定并按模板发起审批，不在本系统新建审批模板或设计审批节点。账号身份不采用用户扫码自助绑定；通过企微通讯录接口获取成员，在系统账号列表中由管理员维护系统账号对应的企微 userid。退款、员工线下代充等业务发起审批后，通过企微回调接收结果，并保留查询审批详情/轮询作为回调丢失时的补偿。是否能取得审批人 userid 并映射为系统账号名称，以企微官方接口实际返回能力为准，不能为列表展示另建复杂审批人模型。

### #40 下架套餐老客户续费

- 原始需求：正在使用下架套餐的客户仍可自行续费；新客户不可购买；代理不可代购。
- 当前判断：未完成；有购买资格校验，但不需要迁移整个套餐模块。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个要做,主要是提供一个续费接口,只有通过这个接口才能去购买下架后的套餐(我记得是这样设计的),然后确保C端的可购套餐列表中没有下架的套餐,其次就是可以在历史订单里面续费,应该也是用同一个接口

### #42 导出功能

- 原始需求：分别支持 lot 卡、钱包流水、套餐、退款、换货、代理充值六类导出及指定字段。
- 提案问题：将六个独立导出需求扩大成统一字段权限平台，并依赖多个未完成业务。
- 建议：按业务场景逐个交付，优先使用现有导出框架，不阻塞在“统一平台全部完成”。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个没啥好说的,确保按照我们有的字段,以及业务要求的字段去导出即可,可能需要探索一下,如果有字段我们没有,需要决定一下是否要加

### #47 限速规则

- 原始需求：根据不同运营商规则，基于套餐流量设置卡/设备限速规则。
- 提案偏差：改成后台手动选择固定档位并调用 Gateway，明确排除自动限速。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：改成后台在 IoT 卡详情手动选择固定档位并调用 Gateway；Gateway 只支持按卡 ICCID 限速，设备没有限速接口，也不通过设备绑定卡间接限速

### #48 按资产类型限制支付方式

- 原始需求：卡只允许支付宝/钱包，拒绝微信；设备只允许微信/钱包，拒绝支付宝。
- 当前判断：未完成；前端展示和后端订单/支付强校验都需要实施。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：这个其实就是在system_config里面做一个参数修改而已,通过这个参数可以决定卡/设备的支付方式限制,这个我们的迭代方案中好像说明是对的,其他的就是在C端不知道有没有东西能让前端判断展示哪些支付方式了

### #49 设备批量分配代理和套餐系列

- 原始需求：上传 Excel，以设备号批量分配代理或套餐系列。
- 提案偏差：改成 CSV、异步五态任务、对象存储和失败明细平台。
本期决定（单选）：

- [X] 本期做
- [ ] 已完成，只联调/验收
- [ ] 后置
- [ ] 不做
- [ ] 待确认

- 说明：是改成csv了,其他跟现在导入没有什么区别,就是业务不一样

---

## 五、已关闭需求回归确认

以下 5 条在 CSV 中未挂七月计划且已关闭。默认不重新开发；如本次需要回归，请勾选。

### #168 停机阈值显示

- 原始需求：虚流量停机阈值显示为真流量总量。
本期决定（单选）：

- [ ] 仅回归
- [ ] 重新修改
- [X] 不处理

- 说明：已经做过了

### #90 资产详情敏感字段展示调整

- 原始需求：代理/企业只显示运营商名称，不显示运营商账户；代理不显示设备实名策略和制造商。
本期决定（单选）：

- [ ] 仅回归
- [ ] 重新修改
- [X] 不处理

- 说明：

### #75 支付配置命名调整

- 原始需求：“微信配置”改名为“支付配置”，同步权限编码和路由命名。
本期决定（单选）：

- [ ] 仅回归
- [ ] 重新修改
- [X] 不处理

- 说明：

### #64 H5 设备支持支付宝

- 原始需求：H5 设备支付增加支付宝。
本期决定（单选）：

- [ ] 仅回归
- [ ] 重新修改
- [x] 不处理

- 说明：

### #63 授权列表滚动条和字段顺序

- 原始需求：代理系列授权套餐列表增加滚动条，调整后台资产字段展示顺序。
本期决定（单选）：

- [ ] 仅回归
- [ ] 重新修改
- [x] 不处理

- 说明：

---

## 六、填写完成后

填写完成后通知后端复核即可。后端将根据选择结果重新整理 OpenSpec 提案和实施顺序。