This commit is contained in:
220
docs/product/2026-08-迭代-PRD-讨论稿.md
Normal file
220
docs/product/2026-08-迭代-PRD-讨论稿.md
Normal file
@@ -0,0 +1,220 @@
|
||||
# 新卡管 2026 年 8 月迭代 PRD（讨论稿）
|
||||
|
||||
> 状态：讨论中
|
||||
>
|
||||
> 本文是本轮需求澄清的唯一决策记录。确认后的需求将重编稳定需求 ID；每项实施前再以独立 OpenSpec Change 固化可观察行为、任务和验收。
|
||||
>
|
||||
> 来源：业务提供的《新卡管 8 月迭代需求》，2026-08-11。
|
||||
|
||||
## 0. 已确认的产品边界
|
||||
|
||||
1. 本文覆盖一个需求池，不承诺整体一次上线。完成完整 PRD 后，按影响范围由小到大拆分为独立 Change 实施。
|
||||
2. 原文编号存在重复和漂移。讨论稿将建立新的稳定需求 ID；原编号仅用于追溯来源。
|
||||
3. 审批类业务必须接入企业微信。企业微信是唯一终审来源；审批节点、审批人、条件和流转规则完全由企业微信模板配置，本系统不读取、校验或固化这些规则。系统只保存本地审批实例、业务状态、审计和幂等闭环，并按企业微信最终通过或驳回结果推进业务；不提供本地人工通过或拒绝来绕过企业微信。企业微信回调延迟、提交失败或结果未知时，使用既有兜底轮询查询渠道状态并同步本地实例。
|
||||
4. OCR 是已有的外部能力，但本期仅作为交易流水号的预填来源。申请人或审核人必须能更正并最终确认；OCR 识别结果不是资金事实。OCR 协议、字段能力、失败和重试规则等待外部契约文档。
|
||||
|
||||
## 0.1 稳定需求 ID 与原文映射
|
||||
|
||||
| 稳定 ID | 能力 | 原文来源 |
|
||||
| --- | --- | --- |
|
||||
| AUG26-001 | 员工代收款账单与核销 | PRD-08-001、PRD-08-013（核销字段） |
|
||||
| AUG26-002 | 支付商户池与微信授权配置 | PRD-08-002 |
|
||||
| AUG26-003 | 店铺业务员与业务用户组 | PRD-08-004、PRD-08-005 |
|
||||
| AUG26-004 | 套餐真流量预警 | PRD-08-006 |
|
||||
| AUG26-005 | 换货业务数据迁移展示 | PRD-08-007 |
|
||||
| AUG26-006 | 套餐退款与原路退款 | PRD-08-008、PRD-08-013（退款字段） |
|
||||
| AUG26-007 | H5 风险换卡与运营通知 | PRD-08-009 |
|
||||
| AUG26-008 | 代理分销码、资料资格与佣金提现 | PRD-08-010、PRD-08-013（提现/分销审批字段） |
|
||||
| AUG26-009 | 手机号—资产关联 | PRD-08-011 |
|
||||
| AUG26-010 | 自动续费 | PRD-08-012 |
|
||||
| AUG26-011 | 运营商通道流量阈值 | PRD-08-017 |
|
||||
| AUG26-012 | 佣金回溯明细 | PRD-08-015 |
|
||||
| AUG26-013 | 资产套餐层级展示 | PRD-08-016（资产详情） |
|
||||
| AUG26-014 | 导出与统一时间筛选 | PRD-08-014、PRD-08-020 |
|
||||
| AUG26-015 | 报表管理 | PRD-08-016（报表，原编号重复） |
|
||||
| AUG26-016 | 优先轮询通道 | PRD-08-019 |
|
||||
| AUG26-017 | 代理自充收款方式 | PRD-08-021 |
|
||||
|
||||
## 1. 已确认的领域语言
|
||||
|
||||
### 1.1 员工代收款账单
|
||||
|
||||
员工代客户购买套餐、充值等业务时，系统按来源业务生成的待核销记录。它表示员工经办业务形成的暂挂欠款；员工提交客户付款凭证，企业微信审批人员可通过该凭证在外部第三方收款记录中核验支付，且企业微信审批通过后，欠款相应减少或结清。客户款项可支付至公司微信、银行卡或其他由业务维护并认可的线下收款方式，不要求必须支付给员工或由员工另行回款。
|
||||
|
||||
代理线下预存款/主钱包充值仍按既有企业微信审批决定是否入账；该审批通过并完成入账后，系统再创建相应员工代收款账单，使员工欠款增加。后续账单核销是独立于充值审批的业务流程。
|
||||
|
||||
员工代收款账单的欠款人固定为实际发起线下套餐订单或线下代理充值的后台账号，创建后不可修改；平台业务员和超级管理员实际经办时均生成本人账单。员工离职或账号禁用后，其欠款人身份不变；仅超级管理员可代办创建、修改或重新提交核销申请，且必须记录实际代办人及代办原因。
|
||||
|
||||
已确认：支持一笔外部支付记录分摊核销多张账单，也支持一张账单由多笔支付记录分次核销。员工应按一笔外部付款创建一张核销申请，在申请中上传该笔付款的凭证、填写交易流水号，并选择多张账单及各自分摊金额；一张申请只产生一个企业微信审批实例。每笔分摊必须独立保留账单、外部支付记录标识、本次核销金额、凭证、审批实例和剩余未核销金额。
|
||||
|
||||
员工代收款账单的核销状态独立于核销申请审批状态：账单状态为待核销、部分核销、已核销或已关闭；申请状态为审批中、已通过、已驳回、已撤销/已关闭。只有企业微信审批通过的分摊才减少员工欠款。账单列表需同时展示账单核销状态和是否存在审批中申请，避免部分核销与审批中互相覆盖。
|
||||
|
||||
企业微信最终驳回的核销申请允许员工在原申请上修改后重新提交；系统为同一申请保留每一次企业微信审批实例及其当次业务快照，历史材料和审批结果不得被覆盖。已驳回申请可修改全部申请内容：收款账户、外部付款信息、附件、备注、勾选账单和分摊金额；已通过的分摊不可修改。
|
||||
|
||||
超级管理员可关闭待核销、已驳回或部分核销账单，关闭即作废当时未核销余额且不再计入员工欠款；已核销金额保留。关闭必须填写原因、保留操作审计，且存在审批中核销申请时不得关闭。
|
||||
|
||||
已确认：员工代收款账单按业务场景确定公司应收金额。
|
||||
|
||||
- 代理代购套餐：取订单 `actual_paid_amount`（代理实际结算/成本金额）。对会生成员工代收款账单的后台线下套餐订单，创建订单时不再强制上传付款凭证；订单仍按当前规则立即激活，并同时创建待核销账单。付款凭证、OCR 与外部交易流水号只在后续核销申请提交。赠送套餐等不产生员工账单的线下订单继续保持创建时上传凭证的当前规则。
|
||||
- 无代理归属的自营 C 端套餐购买：取订单 `actual_paid_amount`。当前实现该值等于 `total_amount`；未来优惠券等价格优惠也应使其表示实际收款金额。
|
||||
- 代理线下充值预存款/主钱包：既有充值审批通过并入账后创建员工代收款账单，金额取 `tb_agent_recharge_record.amount`。
|
||||
- 不支持平台代理 C 端客户充值资产钱包；原需求中对此类场景不纳入本期。
|
||||
- “其他”来源第一版不支持手工创建，必须先定义可追溯来源单和金额口径。
|
||||
|
||||
> 待决：`actual_paid_amount` 在未来优惠场景的写入时机与权威性；外部支付记录在本地的最小留存字段、收款账户目录的范围和退款时的冲销规则。
|
||||
|
||||
## 2. 当前发现的需求结构问题
|
||||
|
||||
| 问题 | 处理原则 |
|
||||
| --- | --- |
|
||||
| `PRD-08-013`、`014`、`015`、`016` 在范围表与正文含义不一致 | 后续以新稳定 ID 重编，保留来源编号。 |
|
||||
| 审批字段在第 17 节集中出现，但相关主需求中存在不同口径 | 先定义每个审批业务的业务单、状态、资金生效时点和企业微信模板，再定义页面字段。 |
|
||||
| OCR 被写入字段说明但缺少外部契约 | OCR 仅预填，待提供契约后再定义使用范围。 |
|
||||
| 收款方式被写为固定示例（如某人微信/支付宝） | 收款方式由业务字典维护，不得将名称硬编码为支付方式枚举；是否还需独立收款账户目录待确认。 |
|
||||
| 多处要求“字典维护”，但当前系统没有业务字典 | 新建通用业务字典模块；字典分类由研发固定注册，业务只维护分类下的字典项。已被业务单引用的字典项不得物理删除，只能停用并保留历史名称快照。 |
|
||||
| 自动续费含“有余额自动续费，不停机” | 必须先区分续费订单、钱包扣款、运营商停复机和轮询同步，不能将它们描述为同一动作。 |
|
||||
| 运营商通道阈值、套餐流量预警都使用“阈值” | 前者是通道控制规则，后者是套餐预警规则；二者的流量口径、周期和触发后果必须独立定义。 |
|
||||
|
||||
## 2.1 已确认的外部付款分摊边界
|
||||
|
||||
1. 同一笔外部付款可覆盖多张员工代收款账单，也可由多个员工的多张核销申请引用。
|
||||
2. 本期不对同一外部付款在多张申请中的累计分摊金额做系统防重或金额上限校验；企业微信审批人员以外部第三方记录为准核验。
|
||||
3. 系统仍须逐核销申请保存所选线下收款方式、交易流水号、付款金额、付款方、付款时间、支付凭证、其他凭证、备注及分摊明细，供超级管理员和企业微信审批追溯。交易流水号和付款金额可由 OCR 预填，但必须允许人工确认或更正。
|
||||
4. 员工通过勾选账单创建分摊明细，不手填账单编号、订单、客户或资产字段；系统自动带出这些只读信息。系统按账单产生时间由早至晚，使用本次外部付款金额自动填充分摊，最后一张填剩余金额；员工可以修改本次核销金额。对同一账单的审批中分摊应预占可核销余额，避免并发申请超额核销。
|
||||
5. 本期只做一套固定分类的线下收款方式字典。超级管理员维护字典项名称、稳定编码、排序、启停、备注；核销申请和预存款审批选择字典项并冻结名称快照。不额外建设收款账户目录。
|
||||
|
||||
## 2.2 已确认的历史数据边界
|
||||
|
||||
1. 员工代收款账单仅对功能上线后新创建的符合条件线下套餐订单、功能上线后审批通过并入账的线下代理预存款/主钱包充值自动生成。
|
||||
2. 不回填、不补建任何上线前历史业务；上线前业务不纳入员工账单和欠款统计。
|
||||
|
||||
## 2.6 已确认的商户池覆盖范围
|
||||
|
||||
1. C 端套餐购买、C 端资产钱包充值、代理在线预存款充值三类当前线上收款入口，均应按支付方式通过商户池选择实际收款商户；后台钱包/线下套餐订单不经过商户池。
|
||||
2. 平台范围内每种支付方式最多一个启用商户池；可保留停用历史池，但不得同时启用多个相同支付方式的商户池。未来需要多池时，必须先定义订单/店铺/资产等路由维度。
|
||||
3. 新建独立商户管理模块，收款凭证与商户支付能力从现有综合支付配置中分离，由商户池选择商户；不复用现有支付配置记录作为商户。一个商户仅对应一种支付方式：微信商户和支付宝商户分别建档、分别加入对应商户池。
|
||||
4. 新建独立微信授权配置，平台范围内最多一个启用配置，保存 C 端公众号 H5 登录/JSSDK 和小程序登录所需参数；C 端微信登录、AppID、JSSDK 与 OpenID 只使用该全局配置。微信商户仅保存微信支付或富友收款凭证；商户池命中的微信商户统一使用全局授权配置的 AppID 发起支付，微信侧 AppID 与商户的绑定/授权由业务保证。微信直连商户和富友商户都属于微信支付商户，可混合加入唯一启用的微信商户池；系统按命中商户自身服务商凭证执行支付、回调验签和退款。
|
||||
5. 商户停用后仅对新支付单自动跳过；已命中该商户的历史支付单不换商户，支付回调、状态查询及后续原路退款仍使用该商户凭证。被历史支付单引用的商户不得物理删除，只能停用。商户原路退款能力不提供人工开关，系统仅按服务商类型及退款所需凭证是否完整判定；服务商实现不支持退款的商户固定视为不支持。商户池没有可用商户或商户池停用时，创建支付单失败且不得回退到旧全局支付配置。
|
||||
6. 上线时从当前生效综合支付配置一次性自动迁移：创建一条全局微信授权配置、具备完整凭证的微信/支付宝商户及各自包含一个商户的启用商户池。新订单仅走商户池；旧综合支付配置和历史订单引用保留，仅服务历史回调、查询和退款，不自动改写。缺少完整凭证的支付方式不创建商户池，新支付单按暂无可用商户失败。迁移仅在数据库内复制密钥/证书，不得在日志、审计详情或接口响应暴露敏感值。
|
||||
7. 商户保存名称、支付方式、服务商类型、商户号/应用标识、敏感凭证、状态和备注。每笔新支付单保存实际商户 ID 并冻结名称、支付方式、服务商类型及商户号/应用标识快照，不复制敏感凭证。被支付单引用后，支付方式、服务商类型和商户号/应用标识不得修改；名称、备注、状态及凭证可更新。历史支付单和退款单优先展示快照，回调和退款读取商户当前有效凭证。
|
||||
8. 超级管理员和平台用户均可创建、修改、启用、停用商户、商户池和微信授权配置；其他角色没有管理入口。为使配置人员可核对完整配置，管理 API 的列表和详情向上述已认证角色返回商户及微信授权配置的完整密钥、证书和私钥字段，不做脱敏；不得将这些字段写入日志、审计快照、错误信息或普通业务单据。未被任何支付单命中的商户，超级管理员或平台用户可先将其移出商户池后经二次确认删除；删除审计不得含敏感凭证。被支付单引用的商户一律不得删除。
|
||||
9. 每笔通过商户池创建的支付单，除实际商户 ID 和商户身份快照外，还须保存商户池 ID、商户池名称快照和轮询方式快照；不另建逐次支付路由日志表。
|
||||
10. 金额阈值、笔数阈值和时间周期均为商户池统一配置，池内所有商户共用，不支持成员单独配置。
|
||||
6. 金额/笔数轮询创建池时必须配置统计周期，支持每轮累计、自然日累计、自然月累计。每轮累计在商户重新被轮到时清零；自然日/自然月累计在周期边界重置，达到阈值的商户在当期自动跳过。当前周期所有商户都达到阈值时，创建支付单失败并提示当前周期暂无可用商户。
|
||||
7. 时间轮询创建池时必须配置周期数值、分钟/小时/天单位和起始时间。自起始时间起按固定周期、商户列表顺序轮换；进入新时段时仅在有新支付单时选择并记录商户。当前商户停用时即时跳到下一个可用商户，时间段不重置；修改时间周期、起始时间或商户顺序后，保存成功时间成为新起点并从列表第一项重新计算。时间周期最小为 1 分钟。
|
||||
8. 金额/笔数轮询仅修改阈值时保留当前统计周期内的成功收款累计并立即按新阈值判断；修改统计周期或在金额/笔数两种方式间切换时，保存成功即开始新统计周期、所有商户从零累计。新增商户从零开始；移除/停用商户不再参与新订单选择。调整商户排序时，自然日/自然月累计保留未移除商户的当期累计；每轮累计从新列表第一项开启新一轮、所有商户从零累计。
|
||||
9. 商户预下单失败时不自动切换商户或重试；任一失败按当前错误处理返回，客户再次发起支付时重新按商户池选择。失败订单不计入金额/笔数成功累计。
|
||||
10. 金额/笔数轮询严格仅统计支付成功结果，不在预下单时预占商户额度或笔数；并发预下单可同时命中当前商户，已创建支付单不因后续轮询切换而改挂商户。
|
||||
11. 支付成功后发生的全额或部分退款不回冲商户池金额/笔数成功累计；退款是独立后续资金动作。
|
||||
|
||||
## 2.3 已确认的退款完成规则
|
||||
|
||||
1. 客户提供收款信息的退款以企业微信最终通过为退款完成时点；系统不感知、也不以外部线下实际打款、交易流水号或付款凭证作为退款状态条件。企业微信审批通过即标记已退款。
|
||||
2. 原路退款经企业微信最终通过后，系统必须以原实际收款商户自动调用渠道退款接口，超级管理员不得改选其他商户。只有渠道明确退款成功后退款单才标记已退款并保存渠道退款流水号；调用失败、超时或结果未知时，退款单保持原路退款处理中/失败，保留可恢复事实且不得重复退款。需改为凭证退款时，必须重新提交申请并重新走企业微信审批。
|
||||
3. 原路退款在选择方式、提交申请和实际执行前均重新校验原支付单、原实际收款商户、原渠道交易流水号、商户退款能力/凭证以及可退金额。商户停用不阻断历史订单原路退款。渠道实际调用是退款资格的最终判断；渠道明确拒绝、超期、凭证失效或余额不足时不标记成功、保留失败原因。系统不额外提供退款凭证预探测接口。
|
||||
4. 一笔订单最多只允许一张最终退款成功的退款申请；该申请可部分退款，成功后订单剩余未退款金额不再允许申请退款。
|
||||
5. 退款申请提交金额即企业微信审批授权金额和最终允许退款金额。原路退款按此金额调用渠道；凭证退款实际转出此金额后才可成功。金额需变更时不得继续执行原申请，必须重新提交并重新走企业微信审批。
|
||||
6. 一笔订单同一时间最多一张审批中、原路退款处理中或原路退款失败的退款申请。企业微信驳回、申请撤销/关闭或原路退款明确失败后，允许修改未成功退款申请并重提；可修改金额、原因、退款方式、客户收款信息和附件。每次重提必须新建企业微信审批实例及业务快照，历史材料不可覆盖。任一退款方式最终成功后，申请和订单均不得再发起退款。
|
||||
7. 企业微信最终通过即按当前规则使退款关联套餐失效、接续下一套餐并在必要时停机；原路退款渠道或线下实际打款的后续结果不影响套餐失效，也不恢复权益。
|
||||
8. 凭证退款申请必须提供客户收款账户信息和客户提供的收款凭证，作为企业微信审批材料；不要求、也不提供公司实际线下付款后的交易流水号或付款凭证回填。
|
||||
9. 超级管理员、平台用户和代理均可在各自数据权限内对已支付套餐订单发起退款申请；企业微信是唯一终审来源，本地不提供人工通过、拒绝或退回操作。任一具有该订单数据权限的上述账号，均可修改并重新提交未成功退款申请。
|
||||
10. 凭证退款的客户收款账户信息使用一个必填自由文本字段留存，客户提供的收款凭证附件必填；不新增退款收款账户类型字典、账户表，且不得复用公司线下收款方式字典。
|
||||
11. 退款申请的实收金额必须由系统从来源订单/原支付记录自动带出并冻结，提交人不可填写或修改。线上支付取原成功支付记录金额；资产钱包、代理预存款和后台线下订单取来源订单的实际收款或实际扣款金额。退款金额不得超过冻结实收金额；无法确定权威实收金额时拒绝创建申请。
|
||||
12. 本期不按套餐已用流量自动计算退款金额；提交人填写申请金额，系统仅校验不超过冻结实收金额，套餐使用情况作为退款原因、凭证和企业微信审批判断材料。
|
||||
13. 企业微信在本地收到通过前发生驳回、撤销或删除时，退款申请进入审批未通过/已关闭，未发生退款且可修改重提。企业微信通过后撤销时，不回滚已失效套餐、已发起原路退款或已完成凭证退款；申请标记审批异常、保留审计、禁止自动重提，由超级管理员线下处理。企业微信提交失败或结果未知时，退款申请仍为在途，不允许另建或重提，使用既有查询/重试闭环确认渠道是否受理。
|
||||
14. 对线上支付订单，系统在申请退款时预检可本地确定的原路退款条件：条件满足时同时提供原路退款和凭证退款；条件不满足时禁用原路退款并说明原因，只允许凭证退款。后端在提交及企微通过后的实际执行前均重复校验；后续条件失效时不得强行原路退款。钱包、预存款和后台线下订单不展示不适用的退款方式。
|
||||
15. 所有退款申请必须填写退款原因；退款原因冻结在当次企业微信审批快照中。
|
||||
16. 当前业务实际上限制一张订单仅购买一个套餐；虽数据模型预留多套餐订单能力，但本期退款申请不提供套餐选择，系统自动带出订单唯一关联套餐及其使用情况。企业微信通过后失效该套餐；若为主套餐，仍按现有规则连带失效其加油包。退款上限只按订单冻结实收金额校验。
|
||||
|
||||
## 2.4 已确认的退款方式矩阵
|
||||
|
||||
| 来源订单的实际支付方式 | 本期允许退款方式 |
|
||||
| --- | --- |
|
||||
| 微信/支付宝等线上支付套餐订单 | 原路退款、客户提供收款信息退款 |
|
||||
| C 端资产钱包余额支付套餐订单 | 仅自动退回原资产钱包 |
|
||||
| 代理预存款/主钱包支付套餐订单 | 仅自动退回原代理预存款钱包 |
|
||||
| 后台线下套餐订单 / 员工代收款套餐订单 | 仅客户提供收款信息退款 |
|
||||
| 代理充值预存款业务单本身 | 当前退款模块不覆盖，需另立需求 |
|
||||
|
||||
## 2.5 已确认的退款联动
|
||||
|
||||
1. 来源订单全额退款且账单从未核销时，系统自动关闭账单，关闭原因记为来源订单全额退款。
|
||||
2. 来源订单部分退款且账单从未核销时，系统按退款金额冲减账单应收金额，并保留来源订单退款冲销记录。
|
||||
3. 账单存在任一已通过核销分摊时，系统不得自动冲销该账单；后续由超级管理员人工处理。
|
||||
4. 已核销账单的来源订单后续退款不恢复员工欠款；账单详情仅提示来源订单已退款并保留退款关联。正常订单退款不等于员工欠款重新产生。
|
||||
|
||||
## 2.8 已确认的手机号绑定基线
|
||||
|
||||
当前系统已有个人客户手机号绑定和全局 H5 强制绑定开关；是否强制绑定由全局配置决定，不存在、也不新增按资产导入批次设置“是否需要绑定手机号”的能力。原 PRD 第 15.4 节与当前行为冲突，不能作为本期新增功能依据。本期保留既有全局强制绑定逻辑，并新增已验证手机号与资产的关联记录：同一手机号最多关联 10 个当前有效资产，资产详情展示关联手机号，后台支持按资产解绑、批量解绑及操作记录。全局强制绑定开启时，客户首次登录一项尚未关联该手机号的资产，必须再次完成短信验证码校验后才建立关联；已关联该手机号的资产不再重复验证。全局强制绑定关闭时，H5 登录不要求短信验证码且不新增手机号—资产关联，已有关系保留并可后台查看、解绑。客户更换手机号并完成旧、新手机号验证码校验后，系统原子迁移旧手机号全部有效资产关联至新手机号；新手机号现有关联数加待迁移数超过 10 时整次换绑失败，原关系不变。资产详情列出全部当前关联手机号，单个解绑须明确选择一条资产手机号关系；批量解绑和 Excel 按资产标识导入解绑时，解除每项资产全部当前有效手机号关联，必须二次确认、填写原因并逐条记录实际解除关系。批量解绑逐资产独立执行：有权限且已绑定的资产成功解绑，其余资产失败；任务返回成功数、失败数和逐行失败明细，无权限项使用统一失败文案。具备资产数据权限的后台账号在资产详情、列表、导出和批量任务结果中均展示完整关联手机号，不做脱敏；操作日志不得记录完整手机号。仅超级管理员和平台用户可在资产数据权限范围内执行单个解绑、批量解绑和 Excel 导入解绑；代理、企业和个人客户没有后台解绑能力。手机号—资产关联只能由 H5 短信验证建立，后台不提供补录，后台仅查看和解绑。上线时不回填既有个人客户手机号与资产关系；功能上线后，既有客户首次登录每项资产仍须重新短信验证建立关联，超过 10 项时阻断本次新关联。换货不迁移手机号—资产关联，新资产首次访问时按全局开关重新验证。
|
||||
|
||||
## 2.7 已确认的业务用户组
|
||||
|
||||
1. 业务用户组用于标记平台用户所属业务，既不是后台权限角色，也不是代理店铺分组。
|
||||
2. 每个启用的平台用户最多属于一个启用的业务用户组；用户组不改变后台角色权限、数据范围或店铺具体业务员归属。
|
||||
3. 店铺所属用户组由当前绑定的平台业务员所属用户组实时推导；更换店铺负责人或负责人更换用户组后，店铺所属组随之变化。店铺未绑定负责人、负责人未分组或所属组已停用时，店铺所属组为空或显示已停用。店铺列表、详情和筛选均支持展示及按该推导用户组查询。
|
||||
4. 用户组停用后不得新增成员；现有成员关系保留，用户及其负责店铺均显示该组已停用。停用不影响用户登录、权限、数据范围和店铺负责人，管理员可后续改组或清空成员。
|
||||
5. 仅无成员的用户组可由超级管理员或平台用户二次确认删除；仍有成员时只能停用或先移走成员。
|
||||
6. 超级管理员和平台用户可勾选多个平台用户，批量设置为某个启用用户组或批量清空所属组；设置会直接替换原所属组，停用组不得作为批量目标。
|
||||
7. 超级管理员和平台用户可勾选多家有数据权限的店铺，批量设置为某个启用的平台业务员或批量清空业务员；店铺所属用户组随负责人实时推导更新。批量操作先校验全部目标店铺，任一店铺无权、不存在、已删除或目标业务员无效时整批不修改并统一失败。
|
||||
8. 用户组维护名称、稳定编码、排序、启用状态和备注；不设上级组、层级或组管理员。编码创建时必填、当前未删除用户组内唯一且创建后不可修改；名称、排序、状态和备注可修改。
|
||||
|
||||
## 2.10 已确认的 H5 风险换卡弹窗
|
||||
|
||||
广电风险停机自动弹窗只在当前 H5 登录并访问的资产同时满足以下条件时展示：资产为广电卡、运营商回传扩展状态为风险停机、且不存在待填写收货信息、待发货、已发货待确认或已完成的物流换货单。命中后向当前客户展示换卡提醒。客户提交地址后自动创建一张关联该旧资产的物流换货单；不另建风险换卡待处理记录。首次提交地址即锁定，客户后续不得修改，只能联系后台处理。风险换卡自动创建的物流换货单不在客户提交地址时预设业务数据迁移；后台发货并选择新资产时，仍由操作人按既有换货流程决定是否迁移。同一客户、同一资产的风险换卡弹窗每天最多展示一次；客户点击稍后处理后当天不再展示，次日仍命中条件时可再次展示。运营主动弹窗按店铺、设备类型、卡类型等已配置维度同时匹配；同一维度多选满足任意一个即可，未配置任何适用范围则面向全量客户。主动弹窗配置必须设置优先级；后端按请求条件仅返回优先级最高的一条，优先级相同取最近更新时间最新的一条，风险换卡通知固定高于主动弹窗。H5 弹窗复用个人客户站内通知记录，投放后同时出现在 H5 通知列表供查看历史内容。后端创建或返回弹窗候选时通知保持未读；H5 在客户关闭弹窗、点击操作按钮或进入通知详情后调用现有已读接口。运营主动弹窗仅在客户请求配置页面的候选弹窗时实时匹配并创建或复用通知，未访问 H5 的客户不预生成通知。后台固定支持首页、资产详情、套餐购买、资产钱包充值四种展示页面。频率仅支持每个客户对每条配置仅一次或每天一次。运营配置修改标题、内容、范围、页面、频率或有效期只影响后续投放，既有通知保留原快照；已修改配置作为新版本，对原“仅一次”配置的命中客户可重新投放一次。运营弹窗可不设操作，或设置一个受控按钮，目标仅可为套餐购买或资产钱包充值；不得配置任意 URL。H5 请求候选必须携带当前页面资产标识，店铺、设备类型和卡类型均按该资产匹配，首页由 H5 传当前选中的资产。运营弹窗配置到期或停用后停止新投放，既有通知在通知中心保留 90 天。风险换卡地址提交后停止新投放，既有风险换卡通知保留 90 天。风险换卡收货信息保留收货人姓名、收货手机号和一个完整地址文本三项；地址不拆分省、市、区及详细地址字段。超级管理员和平台用户可管理全局 H5 弹窗配置，代理、企业和个人客户不可管理。
|
||||
|
||||
## 2.9 已确认的换货迁移展示
|
||||
|
||||
换货列表和详情使用“业务数据迁移”及状态：不迁移、待迁移、已迁移、迁移失败；迁移失败可查看失败原因。详情明确迁移范围仅包括资产钱包余额、有效套餐使用记录、累计充值字段和资产标签。资产归属及个人客户—资产绑定属于换货完成固有动作；手机号—资产关联不属于迁移范围，新资产首次访问时按全局开关重新验证。迁移失败时换货单保持原可完成状态，记录最近一次失败原因；超级管理员或平台用户修复条件后可再次确认完成，整套迁移重新原子执行。
|
||||
|
||||
## 2.11 已确认的自动续费基线
|
||||
|
||||
自动续费仅扣待续费同一资产的资产钱包可用余额；对当前有效主套餐续购同一套餐商品，价格按执行时当前渠道可售续费价计算。第一版仅按最终到期前 N 天触发，不按流量阈值触发。平台设置一个总开关，并配置全部主套餐或指定主套餐及统一的到期前 N 天；进入触发窗口后，每项资产每天最多尝试一次，成功即停止，套餐到期后不再自动尝试。余额不足或套餐不可续费时，向当前个人客户及资产所属店铺当时有效业务员创建站内通知；同一资产同一天不重复通知。自动续费成功后，仅当资产处于可恢复停机状态且运营商状态不是风险停机或已销户时，自动调用既有复机；复机失败不回滚已成功的续费和钱包扣款，记录失败并通知客户和业务员。自动任务与手动续购并发时，手动续购优先；自动任务加锁重读后发现人工已完成续购即跳过，避免重复扣款。客户需要额外购买第二个周期时，须在首笔手动订单成功后再次主动下单。
|
||||
|
||||
## 2.12 已确认的代理分销码与提现资料基线
|
||||
|
||||
每个代理店铺创建时系统生成不可修改、全局唯一的随机分销码；二维码仅编码 H5 注册入口和该码。新代理扫码后以手机号短信验证码注册、自行设置密码，并创建待企业微信审批的下级代理及店铺，审批通过后启用。审批通过时新店铺设为分销码所属店铺的直接下级，并复制上级当时业务员为初始业务员，后续双方可独立调整。代理停用后其分销码立即不可注册，既有下级代理和既有佣金关系不受级联影响。
|
||||
|
||||
代理首次提现前提交提现资料资格申请，合同与法人身份证必填，企业微信审批通过且资料未过期才有效；资料变更或过期必须重审。代理提交提现申请时冻结可提现余额、金额、手续费、收款信息和可选发票快照，并自动创建企业微信提现审批，本地不提供人工通过或驳回。合同与法人身份证通过后长期有效，仅资料被代理替换、被超级管理员作废或代理停用时失效。法人身份证正、反面附件均必传。企业代理必须填写统一社会信用代码，个人代理填写法人身份证号；可选发票仅企业代理可上传并校验统一社会信用代码。营业执照、门头照、发票均为可选。合同资格申请必须填写签约主体统一社会信用代码或身份证号；上传发票时由代理填写发票抬头和统一社会信用代码，系统校验其与合同主体代码一致，企业微信审批人员核验附件真实性。企业微信驳回提现申请后，解冻该申请冻结的佣金余额；代理可修改金额、收款信息及本次可选发票后重新提交，每次创建新的企业微信审批实例，资料资格仍有效。企业微信通过即视为代理提现已到账，系统不登记或等待实际线下打款。发票是每笔提现申请的可选材料，如上传则按当前有效合同主体代码校验，并冻结至当次提现企业微信审批快照。
|
||||
|
||||
## 2.13 已确认的流量预警与通道阈值基线
|
||||
|
||||
套餐真流量预警使用套餐实际真流量，阈值为 1%～100% 的小数百分比；每个套餐商品最多一条当前规则，修改覆盖当前值，既有预警冻结阈值快照。按同一资产全部当前有效套餐的真流量用量和总量汇总计算使用比例，并使用主套餐规则判断；同一套餐使用记录与命中阈值只创建一条预警。以实际消耗流量的套餐记录关联资产为准，插拔卡场景同时展示卡和当前关联设备但不汇总多张卡。达到阈值时仅通知资产所属店铺当时有效业务员。规则停用后停止新触发且保留历史；启用或降低阈值后，下次扫描发现已有有效套餐达到阈值即补建预警。
|
||||
|
||||
运营商通道阈值默认关闭；开启时按运营商回传的卡当前计费周期累计流量判断。通道下每张卡独立判断，达量后系统创建可靠停机任务并自动调用运营商停机；达阈值即写入本地通道阈值停机锁，当前周期内拒绝复机，停机调用通过可靠重试或人工恢复确认最终结果。每个通道配置计费周期起始日（1～28，上海时区）。新周期开始后，仅对仍持有通道阈值停机锁、存在有效主套餐且不存在风险停机、销户或其他停机锁的卡自动复机；不符合条件只解除通道锁，不调用运营商复机。自动复机失败记录结果并按既有可靠机制处理。
|
||||
|
||||
## 2.14 已确认的佣金回溯与套餐层级展示基线
|
||||
|
||||
套餐退款佣金回溯后，原佣金记录保持不变，另建关联原佣金记录及退款单的负数佣金明细，佣金明细新增不可提现的“回溯”终态；回溯明细冻结原订单号及其他原佣金字段。部分退款按本次退款金额与订单冻结实收金额的比例，对每条原佣金等比例回溯，按分向下取整、最后一条补足舍入差，累计不超过原佣金。退款发生时佣金计算尚未完成的，等待其终态后再生成全部应有回溯明细；确认无佣金才标记无需回溯。同一退款业务幂等，不重复生成回溯明细。本期只处理套餐退款回溯，换货回溯待独立定义。佣金回溯时直接扣减佣金钱包，允许余额为负；先拒绝并释放待审核提现，再生成回溯明细和扣款流水。
|
||||
|
||||
后台资产详情及 H5 资产套餐历史均返回主套餐及关联加油包的层级结构，直接依据现有 `PackageUsage.master_usage_id` 分组，不新增关联表。加油包按生效时间正序排列，待生效包按购买创建时间正序并排在已生效包之后。无论主套餐或加油包已失效、过期或用尽，均保留层级关系；仅关联主套餐物理缺失时以“关联主套餐缺失”的异常独立项展示。
|
||||
|
||||
## 2.15 已确认的优先轮询定位
|
||||
|
||||
优先轮询是与现有普通轮询并行的高优先级调度队列，而不是一套新的轮询业务逻辑。资产可同时存在于普通轮询和优先轮询，进入优先队列不移除、暂停或改变普通轮询；优先队列仅使该资产额外优先执行同一套既有轮询内容、外部调用及状态同步。一次优先轮询执行成功后任务退出优先队列，资产仍按普通轮询继续运行；外部调用失败或超时按既有失败重试。第一版纳入无有效套餐、套餐过期续购、流量用完购买加油包、人工触发和普通轮询异常补偿五类场景。同一资产有未完成优先任务时，后续触发合并到该任务，追加触发次数、最近时间及来源，不重复调用同一轮普通轮询。优先队列复用普通轮询既有并发上限、失败重试和外部调用保护，仅调度顺序优先，不另建参数配置。
|
||||
|
||||
## 2.16 已确认的导出、时间筛选与代理自充收款方式基线
|
||||
|
||||
临期列表、佣金明细和套餐流量达量预警均复用现有异步导出任务，创建时冻结筛选条件、操作者及可见店铺范围。临期导出一行对应一项资产，取其当前生效主套餐最终到期时间和剩余天数；加油包不单独成行。流量达量预警导出一行对应一条预警记录，套餐、用量、总量、阈值和到期时间使用触发快照，店铺、业务员和用户组按导出执行时当前归属补充。佣金明细的入账后金额冻结每次佣金钱包变动后的实际余额，回溯记录可为负。
|
||||
|
||||
所有要求时间筛选的页面使用统一“开始时间—结束时间”组件和 `start_time/end_time` 参数，支持带时区的 RFC3339 秒级时间闭区间，任一端可不传。IoT/设备任务、换货、分配、订单、代理充值、佣金、提现和导出按创建或申请时间筛选；授权按授权发生时间；临期列表按套餐最终到期时间。导出必须复用当前页面全部筛选条件和创建时数据权限快照。
|
||||
|
||||
代理自充方式由超级管理员维护允许范围（仅微信、仅支付宝、同时支持）；代理实际可用方式取该允许范围与当前可用商户池方式的交集，交集为空时拒绝创建在线充值单。平台用户和代理只可查询实际可用方式。配置变更不影响已创建未支付充值单的支付方式及商户快照，只影响后续新单。
|
||||
|
||||
## 2.17 已确认的报表基线
|
||||
|
||||
激活报表的采购数量以成功导入系统的设备数量计算，不另建采购或入库台账。功能上线后每日生成稳定日报快照；上线前日期不提供报表或明确显示无快照数据，不回填历史。累计激活设备严格采用任一当前关联卡已实名的口径；每日快照中的累计在网设备为已实名且存在有效主套餐的设备，活跃设备为该套餐周期内任一卡真流量大于零的设备，用量为设备当前套餐周期内全部关联卡真流量之和。报表可选择设备名称、型号、制造商、用户组、代理、店铺、业务员中的一个分组维度；未选择时汇总为一行。套餐续费按资产去重，统计期内有主套餐到期的资产计一次到期，至少成功续购一次主套餐计一次续费，续费率不超过 100%。日报快照冻结当天店铺、业务员及用户组归属。后端提供日/月趋势汇总数据和异步导出，图表渲染由前端负责。
|
||||
|
||||
## 2.18 已确认的店铺批量换绑 Excel 基线
|
||||
|
||||
店铺列表勾选批量换绑保持全量预校验、任一项失败整批不更新。Excel 导入复用现有统一导入任务处理方式，逐行执行：成功行提交，失败行不影响其他行，并输出成功数、失败数和逐行失败明细；不设 1000 行硬上限。两种入口均保留。Excel 使用店铺编码唯一定位店铺；换绑时以目标平台用户登录账号唯一定位业务员。每家实际变更店铺复用现有统一审计，记录原业务员、新业务员、操作人、时间和 Excel 行备注；批量任务同时保留汇总结果。
|
||||
|
||||
## 3. 当前阻塞与待后续独立需求
|
||||
|
||||
以下不是本轮继续扩展的产品设计题：
|
||||
|
||||
1. **OCR 外部契约**：仅可作为交易流水号、付款金额等字段的预填能力；接口、字段置信度、失败和重试规则须以外部契约为准。
|
||||
2. **支付渠道契约**：微信直连、富友和支付宝的原路退款接口、超时查询及可恢复错误处理，须以各渠道实际契约为准。
|
||||
3. **运营商契约**：通道计费周期起始日、停复机实际能力及结果未知后的查询/恢复，以运营商接口及业务提供的通道政策为准。
|
||||
4. **换货佣金回溯**：本期只处理套餐退款；“不同资产换货”何时、按何金额回溯佣金未定义，后续如需实施须单独提出需求。
|
||||
|
||||
除上述依赖及独立后续需求外，本轮原始需求的业务规则已收口；后续工作是重编稳定需求 ID、建立原编号映射，并按影响范围拆分独立 OpenSpec Change，不直接开始编码。
|
||||
Reference in New Issue
Block a user