提款渠道限额设置 · PRD

作者 Luke　版本 v1.12　日期 2026-09-14　状态 进行中　平台 BRAND_A & BRAND_B　类 M

L0 · 快速掌握

① 一句话需求

在 充提渠道管理 ▸ 提款渠道管理 的每个渠道新增 设置限额，按总代维护单笔提款最小／最大限额；有记录取本页值，没有记录才取该渠道基本配置。

② 术语写死表

③ 全局红线表

④ 适用范围与「不做」边界

本期包含入口、限额列表、增改删、批量改删、BRAND 筛选、取值优先级、四个权限点与管理员日志。不改 分配设置、查看余额、渠道主数据、玩家端页面／文案、二级代理／单一会员限额、导入导出、告警、限流与异步任务。

1. 页面与资料

1.1 入口

1.1.1 提款渠道列表的操作顺序固定为 分配设置、查看余额、设置限额。设置限额 每行显示；有查看权限即可进入该渠道的整页限额列表，写入权限另判。

1.2 限额列表

1.2.1 标题为 提现管理渠道列表–{对应配置名称}–限额列表。一个渠道一份列表，返回键回提款渠道列表。

1.2.2 默认按 ID 正序。筛选项只有 用户渠道：全部／BRAND_A／BRAND_B。

2. 新增与账号解析

2.1 表单

2.1.1 页顶包含 添加代理（仅限总代） 多行输入、单笔最小限额、单笔最大限额、添加、返回。一次可输入多个总代，共用一组限额。账号栏内提示为 可用逗号、分号、空格或换行分隔。

2.2 容错解析

2.2.1 前后端使用同一条管线：

1. 将英文逗号 ,、中文逗号 ，、英文分号 ;、中文分号 ；、Tab、空格与换行识别为分隔。
2. 去除每项前后空白并跳过空项；连续、开头或结尾分隔符都不报错。
3. 账号按大小写不敏感去重；同批重复只算一项。
4. 以清洗去重后的账号数判断单条／批量与 100 个上限。

2.2.2 清洗后 0 个账号按必填未填；大于 100 个整批不提交并保留输入。不存在“账号格式错误”分支：无法对应账号的字串按“查无此账号”处理。

2.3 对象校验与部分成功

2.3.1 被冻结或停用的总代仍可新增并生效。批量逐条独立写入；有成功项就只回成功数，不列失败明细。0 项成功时，按清洗去重后的输入顺序回报第一项真实失败原因，并逐字沿用该原因在 §5.2 的单条提示语；不得固定回报“非总代”或用后出现的原因覆盖。并发撞唯一键只剔除冲突项。

3. 取值、生效与异常

3.1 限额规则

3.1.1 两个限额都只收 1–50000 的正整数，含端点，不收 0、负数、小数或千分位；最小必须严格小于最大。页面允许配置得比基本配置更宽或更严，不取交集。

3.2 玩家提交取值

1. 以玩家所属总代＋本次提款渠道查本页记录；有记录就取本页最小／最大限额。
2. 没有记录才取基本配置中该渠道的默认限额。
3. 渠道未分配或解析不到总代时，渠道不向玩家显示；基本配置也取不到时，渠道不可用。
4. 本页读取超时／异常时，渠道仍显示，但提交失败并提示重试，同时写系统运行日志；不得回退或放行。

3.2.1 限额作用于总代整条代理线。玩家点击提交时读取并校验一次；保存后的改动只影响之后的新提交，在途提款单不重判。下游只需要拿到本次生效的最小／最大值，不回传来源层级。

4. 修改、删除与批量

4.1 修改

4.1.1 单条与批量共用弹窗。顶部显示 本次将修改 {n} 笔限额配置；总代栏禁用并完整可滚动查看；两个金额栏留空且都必填。确认后把选中记录统一改为同一组值，不设二次确认。请求若带总代字段，拒绝整个请求。

4.2 删除

4.2.1 单条与批量共用二次确认，不设备注。弹窗完整列出选中的总代账号，不截断。确认后物理删除；记录从列表消失，限额立即回落基本配置，同一总代之后可重新新增并取得新 ID。

4.3 选取、并发与结果

4.3.1 批量修改／删除未勾选时不发请求。逐行勾选只在当前页有效；表头全选覆盖当前筛选的全部结果并跨页。批量执行遇已删除或越权项时跳过，其余继续；结果统一显示 操作成功，不显示成功／跳过笔数。

4.3.2 同一记录并发修改以后保存者为准；被删除后再单条修改／删除则提示刷新。重复提交不得产生重复记录或重复删除。

5. 权限、提示与留痕

5.1 权限

5.1.1 后端每次写入都复核权限与目标总代 BRAND；管理员只看得到其 BRAND 范围内的记录。

5.2 后台提示语

5.2.1 格式符号本身不触发提示。系统查询／写入异常沿用后台原始错误呈现，不包装新文案。

5.3 留痕

5.3.1 新增、修改、删除写管理员操作日志，记录对象 ID、总代、渠道、前后值；批量记一条汇总并带对象 ID 清单。批量新增另记提交数、成功数、剔除数及被剔账号。日志不设备注／操作原因。限额读取异常写系统运行日志。

L2 · 验收与附录

文档版本：v1.12 | 日期: 2026-09-14 | 作者: Luke | 文档状态：进行中

Withdrawal Channel Limit Settings · PRD (English)

Author Luke　Source Version v1.12　Translation Version EN-1.5　Date 2026-09-14　Status In Progress　Platforms BRAND_A & BRAND_B　Category M

This file is the English translation of PRD_v1.12_withdrawalChannelLimit.md. The Chinese PRD remains the authoritative source. If the two files differ, follow the Chinese PRD and update this translation.

EN-1.5 aligns Admin Action Log and the Set Limits action with the canonical translation dictionary and source v1.12. Business rules are unchanged.

L0 · Quick Overview

All Master Agent examples in the infographic use the required @BRAND_A suffix.

① Requirement in One Sentence

Add Set Limits to each channel under Deposit & Withdrawal Channel Management > Withdrawal Channel Management. Maintain the minimum and maximum per-transaction withdrawal limits by Master Agent. Use the Limit Record when it exists; otherwise, use the channel's Base Configuration.

② Fixed Terminology

③ Global Invariants

④ Scope

This release includes the entry, limit list, create, edit, delete, bulk edit, bulk delete, BRAND filter, value precedence, four permissions, and Admin Action Log entries. It does not change Assignment Settings, View Balance, channel master data, player-facing pages or copy, Secondary-Agent or individual-member limits, import, export, alerts, rate limits, or asynchronous jobs.

1. Pages and Data

1.1 Entry

1.1.1 The action order in the Withdrawal Channel list is fixed as Assignment Settings, View Balance, and Set Limits. Set Limits appears on every row. A user with view permission can open the channel's full-page limit list; write permissions are evaluated separately.

1.2 Limit List

1.2.1 The title is Withdrawal Channel List – {Configuration Name} – Limit List. Each channel has one list. Back returns to the Withdrawal Channel list.

1.2.2 Sort by ID ascending by default. The only filter is User Channel: All / BRAND_A / BRAND_B.

2. Creation and Account Parsing

2.1 Form

2.1.1 The top of the page contains the multiline Add Agents (Master Agents only) input, Minimum Per-Transaction Limit, Maximum Per-Transaction Limit, Add, and Back. Multiple Master Agents may share one limit pair in a single submission. The account placeholder is Separate with commas, semicolons, spaces, or line breaks.

2.2 Tolerant Parsing

2.2.1 The frontend and backend use the same pipeline:

1. Recognize the English comma ,, Chinese comma ，, English semicolon ;, Chinese semicolon ；, tab, space, and line break as separators.
2. Trim each item and skip empty items. Consecutive, leading, or trailing separators do not produce an error.
3. Deduplicate accounts case-insensitively. A duplicate in the same batch counts as one item.
4. Use the cleaned, deduplicated account count to determine single versus batch handling and the 100-account limit.

2.2.2 Zero accounts after cleaning is handled as a missing required value. More than 100 accounts blocks the entire batch and preserves the input. There is no account-format error branch: a string that does not resolve to an account is handled as an account-not-found error.

2.3 Object Validation and Partial Success

2.3.1 A frozen or disabled Master Agent may still be added and the record takes effect. Process batch items independently. If any item succeeds, return only the success count and no failure details. If zero items succeed, return the first actual failure reason in cleaned, deduplicated input order and reuse that reason's single-item message from §5.2 verbatim. Do not always report “not a Master Agent” or let a later reason overwrite the first one. If concurrent creation hits the unique constraint, exclude only the conflicting item.

3. Value Resolution, Effect, and Errors

3.1 Limit Rules

3.1.1 Both limits accept only positive integers from 1–50000, inclusive. Reject 0, negative values, decimals, and thousands separators. The minimum must be strictly less than the maximum. A Limit Record may be wider or stricter than Base Configuration; do not intersect the ranges.

3.2 Value Used at Player Submission

1. Query by the player's Master Agent and the current Withdrawal Channel. If a Limit Record exists, use its minimum and maximum values.
2. Only when no Limit Record exists, use the channel's default limits from Base Configuration.
3. If the channel is unassigned or the Master Agent cannot be resolved, do not show the channel to the player. If Base Configuration also cannot be read, the channel is unavailable.
4. If the Limit Record read times out or fails, keep the channel visible, but reject submission, ask the player to retry, and write a system runtime log. Do not fall back or allow the request.

3.2.1 The limits apply to the Master Agent's entire agent line. Read and validate once when the player submits. A saved change affects only later submissions; do not re-evaluate withdrawals already in progress. Downstream consumers receive only the effective minimum and maximum values, not the source level.

4. Edit, Delete, and Batch Operations

4.1 Edit

4.1.1 Single and batch edits use the same dialog titled Edit limits for {n} records. The Master Agent field is disabled and the complete list remains scrollable. Both amount fields are empty and required. Confirming applies one limit pair to all selected records. The buttons are Confirm and Cancel. No second confirmation is required. Reject the entire request if it contains a Master Agent field.

4.2 Delete

4.2.1 Single and batch deletion use the same confirmation dialog and do not require Remarks. The dialog lists every selected Master Agent account without truncation. After confirmation, physically delete the records. They disappear from the list, limits immediately fall back to Base Configuration, and the same Master Agent may later be added again with a new ID.

4.3 Selection, Concurrency, and Results

4.3.1 Do not send a batch edit or delete request when nothing is selected. Per-row selections apply only to the current page. Header Select All covers all results across pages under the current filter. During batch execution, skip deleted or unauthorized items and continue with the rest. Always display Operation successful. without success or skipped counts.

4.3.2 For concurrent edits to the same record, the later save wins. If a record has been deleted before a single edit or delete is submitted, ask the operator to refresh. Repeated submissions must not create duplicate records or repeat deletion.

5. Permissions, Copy, and Admin Action Log

5.1 Permissions

5.1.1 The backend revalidates permissions and the target Master Agent's BRAND on every write. Administrators may see only records within their permitted BRAND scope.

5.2 Backoffice Copy

Chinese remains the source copy. The English column is the approved display translation for the bilingual prototype.

5.2.1 Separator formatting does not trigger a message by itself. For system query or write failures, preserve the backoffice's existing raw error presentation and do not add new copy.

5.3 Admin Action Log

5.3.1 Create, edit, and delete actions write Admin Action Log entries containing object ID, Master Agent, channel, and values before and after the change. A batch action writes one summary with the object ID list. Batch creation also records submitted, successful, and excluded counts, plus the excluded accounts. The Admin Action Log does not include Remarks or an operation-reason field. A Limit Record read failure writes a system runtime log.

L2 · Acceptance and Appendices

Source document version: v1.12 | Translation: EN-1.5 | Date: 2026-09-14 | Author: Luke | Translation status: In Progress