feat: 优化通道运营商与金额展示

2026-08-12 13:16:25 +08:00
parent dc358798e9
commit f350bf5ef3
20 changed files with 301 additions and 95 deletions
@@ -371,7 +371,7 @@
 6. 最终失败、超时失败需要退费。
 7. 三网通道成本只用于平台内部成本核算，不影响客户扣费金额。
 8. 当前版本计费口径固定为提交 accepted 扣费、最终 failed receipt/timeout 退款。
-9. 所有面向用户展示的金额、余额、充值金额和单价统一以人民币元展示并固定保留四位小数；内部使用 `0.0001 元`整数金额单位持久化，不以浮点数执行账务计算。
+9. 所有面向用户展示的金额、余额、充值金额和单价统一以人民币元展示，最多保留四位小数并移除末尾无意义的 `0`；内部使用 `0.0001 元`整数金额单位持久化，不以浮点数执行账务计算。通道成本费率作为费率字段固定展示四位小数。
 10. API 必须定时扫描提交成功但超过 72 小时仍未收到明确最终回执的短信，转为 timeout 并退还已扣金额；扫描需覆盖 `submitted` 和 `unknown`，且用条件更新避免多实例重复退款。

 ## 5. 功能需求
@@ -1559,12 +1559,12 @@

 ## 2026-07-16 全平台金额精度要求

-1. 企业应用客户单价、通道成本单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数，页面及导出文件统一展示 4 位小数。利润报表中的收入同样固定展示 4 位小数。
+1. 企业应用客户单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数。页面只读金额最多展示 4 位小数并移除末尾无意义的 0，小数部分与整数使用相同字号、颜色和字重；纯文本导出继续保留业务所需精度。通道成本费率作为费率字段固定展示 4 位小数，不执行末尾 0 裁剪。
 2. 数据库和计费链路继续使用整数运算，最小金额单位统一为 `0.0001 元`，即 `1 元 = 10000 金额单位`。历史字段名中的 `Cents` 为兼容既有 API 暂不改名，但其数值语义同步调整为金额单位，不再表示人民币“分”。
 3. PostgreSQL 金额列统一升级为 `BIGINT`。上线迁移时既有按分保存的数据乘以 100，应用换算除数由 100 改为 10000，确保迁移前后实际人民币金额完全一致。
 4. 企业应用单价修改必须写入真实 `SmsApplication.customerUnitPrice`，例如 `0.0325 元/条` 保存为 `325`；后续预估、冻结、扣费、返还和利润统计均使用该整数值，不得在前端或后端再次四舍五入到分。
 5. API 返回 `BIGINT` 金额时仅在 JavaScript 安全整数范围内转换为 JSON number；超过安全整数范围必须显式报错，避免静默丢失金额精度。
-6. 所有运营端和客户端的只读金额文本，整数部分保持当前文字颜色，小数点及小数部分使用更淡的次级文字颜色；金额输入框和 CSV 等纯文本载体保持原始数值格式，不拆分字符。
+6. 所有运营端和客户端的只读金额文本不得拆分整数和小数样式；运营看板“今日消费”和企业应用“单价”使用所在指标或表格的正常主数字字号与深色文字。

 ## 2026-07-16 企业应用接口参数复制与下游接入约束

@@ -1644,7 +1644,7 @@
 - 人工充值请求必须使用当前会话操作者、8至128位幂等键和账户`updatedAt`版本。相同幂等键同一请求返回原订单/操作单和`replayed=true`；不同范围复用键或账户版本变化必须返回冲突并要求重新核对。
 - RechargeOrder、TenantAccount余额增量、AccountTransaction和OperationLog必须在同一Serializable事务内原子完成；审计记录需包含前余额、变动金额、后余额、订单号、原因和幂等键。正数为充值，负数为冲正，金额精确到小数点后4位且不得为0。
 - 运营端充值记录必须提供可截图的账户充值回执。回执只能使用真实充值订单、企业和关联账务流水数据，展示系统真实Logo、入账状态、企业名称与编码、订单号、入账时间、前后余额、入账方式和备注；不得使用前端临时数据补齐缺失字段。
- 回执的“本次充值金额”按实际精度显示：整数金额不显示小数部分，存在小数时仅保留有效小数位；前后余额继续遵循平台统一的四位金额精度。
+- 回执的“本次充值金额”和前后余额均按平台统一金额规则显示：最多保留四位小数，并移除末尾无意义的 `0`。

 ## 2026-07-22 UI/UX A7公共Dialog契约

@@ -1999,6 +1999,9 @@
 ## 签名清退预警（2026-08-10，已发布到预生产）

 - 企业预警按“企业签名 × 运营商”每天检测，通道预警按“签名 × 通道 × 运营商”每天检测。运营商只要存在当前报备通过任务就进入对应监控名单，不等待三网全部成功；历史通道级任务由一次性migration按最终口径自动转换，不再存在人工确认待办。
+- 企业签名“报备状态”弹窗按移动、联通、电信三列分区展示真实目标通道；每个分区独立滚动、每个通道独立选择状态，三个分区共用修改原因和一次保存操作。运营商使用全局低饱和胶囊标签。
+- 充值回执压缩金额区和垂直留白；常规桌面视口应在不滚动时看到完整回执，异常长备注允许内容区滚动而不得截断真实内容。
+- 短信通道管理按北京时间今日真实提交尝试数降序后再分页；同量按通道名称、ID稳定排序。今日提交为0时，提交失败、送达成功、回执未知、送达失败四个比率统一显示深灰色短杠。运营商低饱和胶囊放在通道信息列底部，原“运营商 / 成本”改为“成本费率”并固定展示4位小数。
 - 企业预警支持移动、联通、电信通用X天/Y条规则和企业应用特殊规则，特殊规则优先；通道预警支持通用规则和通道特殊规则，特殊规则优先。规则修改从下一检测日生效，预警快照保存命中的规则版本和阈值。
 - 清退活跃量按至少有一次上游接受的业务短信去重统计。企业维度同一业务短信只计一次；通道维度按`messageRecordId + channelId`去重，同一通道断连、超时或重试产生多次提交只计一次，切换到不同通道后各通道分别计一次。提交尝试、上游接受和最终送达必须分开展示，不把`SubmitResp status=0`称为最终送达成功。
 - 每天按北京时间完整自然日检测`T-X`至`T-1`。当前连续报备通过时间不足X个完整日时不预警；恢复达标后关闭当前预警周期，以后再次低于阈值形成新周期。每日检测必须以数据库唯一维度保证幂等，多实例或重启不得重复生成消息或Webhook。
@@ -3448,7 +3448,7 @@ npm run verify:phase8
 | TC-BILLING-011 | 分别准备 `余额+授信` 为正数、0 和负数的账户，使用相同短信费用发起发送。 | 和为正数时允许发送；和为 0 或负数时提示余额不足。判断公式为 `balanceCents + creditCents > 0`，与本次费用和套餐无关。 |
 | TC-BILLING-012 | 已扣费短信收到最终失败回执；另一个消息在提交前失败并释放冻结；另准备一笔任务冻结转扣费时的批次级释放。 | 最终失败只生成一条 `refunded` 并计入“今日返还”，重复回执不重复退款；提交前失败生成 `released + relatedType=sms_message_record` 并计入“今日返还”；冻结转扣费的 `released + relatedType=sms_batch_task` 属于内部转换，不计入“今日返还”；客户端和运营端当日金额一致且保留三位小数。 |
 | TC-BILLING-013 | 准备已提交扣费但 72 小时完全无回执的 `submitted` 短信，以及有 `UNKNOWN` 回执且超过 72 小时的短信；分别覆盖HTTP提交、CMPP短短信和多分片长短信，启动 API 定时扫描并模拟投递建单失败后重复扫描。 | 两类短信都转为 timeout、写入`undelivered/EXPIRED/RECEIPT_TIMEOUT`并只退款一次；HTTP产生一个明确失败Webhook，CMPP对每个请求回执的原始分片产生失败状态报告且使用各自SubmitResp Msg_Id；建单未完成时`timeoutReceiptQueuedAt`保持空并由后续扫描补齐，成功建单后不重复；任务进度刷新。 |
-| TC-BILLING-014 | 在运营端充值记录中分别打开整数金额、含1至4位有效小数、负数冲正以及缺少可追溯余额的真实订单回执。 | 每行提供“查看回执”；弹窗左上只使用系统真实Logo；企业、订单号、时间、备注与数据库订单一致；可追溯订单的入账前余额等于入账后余额减本次变动；无快照时前后余额不得伪造；主金额整数不显示小数，非整数仅显示有效小数，余额仍显示四位精度；正数显示已入账，负数显示已冲正。 |
+| TC-BILLING-014 | 在运营端充值记录中分别打开整数金额、含1至4位有效小数、负数冲正以及缺少可追溯余额的真实订单回执。 | 每行提供“查看回执”；弹窗左上只使用系统真实Logo；企业、订单号、时间、备注与数据库订单一致；可追溯订单的入账前余额等于入账后余额减本次变动；无快照时前后余额不得伪造；主金额和余额最多显示四位小数并移除末尾无意义的0；正数显示已入账，负数显示已冲正。 |
 | TC-SEC-006 | 安装 API 生产依赖并执行 `npm audit`；使用缺文件、多文件、超大文件、超量字段和正常单文件调用认证后的 multipart 上传接口。 | NestJS/Multer/Hono 已升级或锁定到修复版本，生产依赖 audit 为 0；接口只接受一个不超过 20MB 的文件，并限制字段、part、字段名、字段值和 header pair 数量；异常请求返回受控 4xx，正常文件仍写入真实 MinIO 和 `FileObject`。 |

 ### 17.5.1 报表对账细化
@@ -4546,6 +4546,13 @@ npm run verify:phase8
 | TC-UI-MONEY-001 | 遍历运营端和客户端包含余额、单价、消费、返还、充值、成本、收入和利润的页面 | 只读金额整数部分沿用主文字颜色，小数点及小数部分使用统一淡色；负号、币种符号和单位位置正确，输入框、复制值和CSV仍为完整纯文本数值 |
 | TC-CLIENT-LOGIN-ANIMATION-001 | 打开客户端登录页并保持页面可见，再切换后台或启用减少动态效果 | Canvas动画在登录框背景平滑运行、不遮挡表单、不响应敏感输入；页面隐藏或组件卸载时停止帧循环，减少动态效果下显示静态背景 |
 | TC-ENTERPRISE-SIGNATURE-STYLE-001 | 打开企业签名管理列表 | 企业名称和企业应用名称使用常规字重，签名名称及状态层级保持原样 |
+| TC-SIGNATURE-CARRIER-REPORT-011 | 打开企业签名“报备状态”弹窗，并准备三网各有多个目标通道 | 移动、联通、电信按三列独立区域同时展示；通道不再铺成一条长列表；每个区域可独立滚动，状态保存仍提交真实“签名×通道×运营商”任务并共用修改原因 |
+| TC-UI-CARRIER-TAG-001 | 检查通道、签名质量、清退预警和手机号段等运营商标签 | 移动、联通、电信复用全局低饱和胶囊组件，颜色克制且文字可辨；业务状态标签不被误改为运营商颜色 |
+| TC-RECHARGE-RECEIPT-002 | 在1366×768桌面视口打开普通充值和冲正回执 | 本次金额区缩小，Logo、企业、明细、备注、说明和完成按钮无需滚动即可完整看到；异常长备注允许弹窗内容区滚动且真实文本不截断 |
+| TC-CHANNEL-SORT-001 | 准备超过一页且今日提交量不同的通道并翻页 | 后端先按北京时间今日提交尝试数降序排列全部筛选结果，再分页；同量按通道名称、ID稳定排序，不出现仅当前页前端排序 |
+| TC-CHANNEL-QUALITY-ZERO-001 | 查看今日提交数为0的通道 | 提交失败、送达成功、回执未知、送达失败四个比率均显示深灰色`-`且不带百分号；对应数量仍为0 |
+| TC-CHANNEL-LAYOUT-001 | 查看短信通道列表 | 运营商低饱和胶囊位于通道信息列最底部横排；独立列标题为“成本费率”，费率固定4位小数且整数、小数同字号同色 |
+| TC-UI-MONEY-002 | 检查运营端、客户端各金额页面及运营看板今日消费、企业应用单价 | 金额整数和小数同字号同色；末尾小数全为0时不显示，非零小数最多4位并移除末尾0；今日消费和应用单价恢复正常主数字深色样式；成本费率固定4位作为例外 |
 | TC-SIGNATURE-RETIREMENT-019 | 检查两张热力图日期、行首和悬停信息 | 日期从左到右为`T-1`至`T-30`；行首不常驻企业和企业应用，悬停签名可看到企业、企业应用；通道维度仍能识别通道和运营商 |
 | TC-SIGNATURE-RETIREMENT-020 | 分别在企业、通道热力图搜索企业、企业应用、签名并清空 | 每张热力图只过滤自身真实维度并回到第一页；三类关键字均可命中，清空恢复，另一张热力图的关键字和页码不变 |
 | TC-SIGNATURE-RETIREMENT-021 | 悬停报备前、无快照、零量和非零量格子 | 报备前显示不适用；无快照说明当日无检测；真实快照明确显示提交条数、上游接受条数、发送成功条数和成功率，发送成功等于真实最终送达而非受理成功 |
@@ -2,6 +2,13 @@

 > 环境命名：当前 `8.160.169.106:12026`（Web/API）和 `8.160.169.106:17890`（CMPP 入站）实例统一定义为“预发布环境”。历史记录中涉及该实例的验证、部署和业务页面均按预发布环境理解；`production-deploy.sh`、`NODE_ENV=production` 及正式生产安全/备份规范保留原有技术语义，不代表该实例为正式生产。

+## 2026-08-12 企业签名弹窗、充值回执、通道列表与金额显示优化（待发布）
+
+- 已确认企业签名报备状态采用“三列运营商分区”方案，运营商标签采用低饱和胶囊方案；本批同步调整充值回执密度、通道今日提交后端排序、零提交比率展示和成本费率布局。
+- 撤回金额小数弱化规则：所有只读金额恢复同字号同色，最多展示4位并裁掉末尾0；通道成本费率固定4位。运营看板今日消费和企业应用单价恢复正常主数字深色样式。
+- 不涉及数据库结构或生产数据迁移。通道服务专项 1 suite/46 项、API 全量 35 suites/453 项、前后端 TypeScript/构建、Gateway `go test ./...`、`go vet ./...`、4 份队列结构契约及 `git diff --check` 已通过；Vite 仅保留既有大分块 warning，测试中的 Redis unavailable 和预期异常日志均为既有受控分支，未伪造外部依赖。
+- 应用内浏览器连接真实本地 NestJS、PostgreSQL、Redis 和 production preview 验收：1366×768 下三运营商报备状态弹窗横向三分区且页面无横向溢出；普通充值回执内容区 `scrollHeight=clientHeight=546`，无需滚动即可看到完成按钮；通道零提交四个比率均为深灰短杠，移动/联通/电信低饱和胶囊色互不相同；运营看板今日消费为 30px 深黑主数字，企业应用单价为深色常规字号。820px 复核弹窗改为单列且页面无横向溢出，浏览器 console error/warn 为 0。验收未保存报备状态、未充值、未启停或编辑通道、未发送短信。
+
 ## 2026-08-12 签名热力图、登录动画、金额样式与利润口径（已提交、已部署）

 - 功能提交 `0cd353450abb999bd9c192c6df482af5e07095b5` 已推送并部署预发布。签名热力图新增 T-1～T-30 合计并按发送量降序，观察期继续保存真实单日快照但不触发预警；企业签名企业/应用文字改为常规字重，客户端登录框新增可降级的 Canvas 动画，金额展示统一弱化小数部分。
@@ -2004,7 +2011,7 @@ git diff --check

 - 根因确认：企业应用编辑页原先按 `Math.round(元 × 100)` 保存，`0.0325 元`只能落为 3 分；PostgreSQL 的余额、流水、单价、计费和利润字段也均为 `Int` 分，无法表达万分之一元。现统一调整为 `1 元 = 10000 金额单位`，字段名中的 `Cents` 仅为兼容既有 API 保留。
 - Prisma 金额列统一升级为 `BigInt`，migration `20260716150000_expand_money_precision_to_four_decimals` 将历史整数分乘以 100。迁移前已备份本地真实 PostgreSQL；抽查 `AccountTransaction、SmsApplication、SmsMessageRecord、TenantAccount` 汇总，迁移后整数值均精确为迁移前 100 倍，按新除数换算后的人民币金额不变。53 条 migration 已全部应用，Prisma schema validate 和 migrate status 均通过。
- 企业应用客户价、通道成本价、授信和人工充值输入均允许最多 4 位小数并转换为整数金额单位；运营端与客户端的余额、授信、今日消费、今日返还、充值、短信详单、客户价、通道价和利润报表统一固定展示 4 位小数。利润 CSV 改为以“元”为表头并导出 4 位小数。
+- 企业应用客户价、通道成本价、授信和人工充值输入均允许最多 4 位小数并转换为整数金额单位；该阶段曾统一固定展示 4 位小数，现已由 2026-08-12 的统一金额样式需求调整为最多 4 位并裁剪末尾无意义的 `0`，通道成本费率除外。利润 CSV 仍以“元”为表头并保留业务所需精度。
 - NestJS 对客户价、通道价、充值、授信、计费规则和计费结果增加安全整数校验；Prisma `BigInt` 响应仅在 JavaScript 安全整数范围内序列化为 number，超限直接报错，避免静默精度损失。计费单测新增 `325 × 2 = 650` 金额单位，企业应用更新单测使用 `customerUnitPrice=325`。
 - 使用真实本地 NestJS API、PostgreSQL、Redis 和 Playwright/Chromium 编辑一条已配置通道组的企业应用：页面填写 `0.0325` 后保存，数据库核对 `SmsApplication.customerUnitPrice=325`，再次进入编辑页仍为 `0.0325`，控制台无 error；随后已恢复原单价并清理临时管理员、角色关联和操作日志。
 - API 全量 20 个 Jest 测试套件通过，其中金额与企业应用目标套件 45 条用例通过；API TypeScript build、前端 TypeScript/Vite 生产 build、Gateway `go test ./...`、Prisma validate/status 和 `git diff --check` 均通过。
@@ -2387,7 +2394,7 @@ git diff --check

 - 运营端充值记录每行新增“查看回执”操作，弹窗直接使用真实`RechargeOrder`、企业信息及订单关联的`balanceAfterCents`，据此计算入账前余额；历史记录缺少可追溯余额时显示`-`，不使用当前账户余额或前端假数据补齐。
 - 回执左上只展示系统现有`/logo/logo1.png`真实Logo；展示入账状态、本次金额、企业名称和编码、订单号、入账时间、前后余额、入账方式与备注，适合客户截图留存。
- “本次充值金额”采用实际精度：整数不显示小数，存在小数时移除末尾无效零；前后余额继续显示平台统一四位精度。正数显示“已入账”，负数冲正显示“已冲正”。
+- “本次充值金额”采用实际精度：整数不显示小数，存在小数时移除末尾无效零；该阶段前后余额曾固定显示四位，现已随 2026-08-12 统一金额样式调整为最多四位并裁剪末尾无意义的0。正数显示“已入账”，负数冲正显示“已冲正”。
 - 金额边界验证结果：`10000.0000 → 10,000`、`10000.2500 → 10,000.25`、`10000.0001 → 10,000.0001`、负数冲正`-123.4500 → 123.45`，符合主金额按实际精度展示口径。
 - 使用Node.js v24.14.0执行前端TypeScript和Vite生产构建通过，保留既有约1.93MB单chunk/579.51KB gzip警告；`git diff --check`通过。首次由系统旧Node执行时Vite不支持`??=`且错误返回0，已明确排除，未将其计为通过。
 - 浏览器加载真实本地前端/API后进入运营登录页，页面标题正确、控制台0条error/warn；由于当前浏览器无有效会话且存在图形验证码，本轮未绕过验证码，登录后的“查看回执”点击与视觉验收仍需人工登录后补测。
@@ -3474,7 +3481,7 @@ git diff --check
 - API、Gateway、Nginx、PostgreSQL和MinIO均active，API/Gateway/MinIO健康、Redis PONG、Stream消费者1、`pending=0`、`lag=0`，运营端、客户端和公网API health均HTTP 200；部署后API/Gateway error和warning级日志为0，运行源码和前端产物均不存在`legacy-report-tasks`或“历史待确认”标记。
 - 9条活动通道重启恢复后6条`connected 1/1`；“会员营销-富泷”“移动物业-富泷”“联电物业-富泷”继续为发布前已知的供应商`authentication`失败。本轮未修改通道账号、密码、启停状态、企业余额或客户连接，没有手工发送、补发或重投短信，也没有修改Webhook。受保护的`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续不删除、不提交、不归因于业务源码提交。

-## 2026-08-12 利润报表收入口径调整（未提交、未发布）
+## 2026-08-12 利润报表收入口径调整（历史开发记录，已随 `0cd3534` 发布）

 - 利润报表“净消费”统一更名为“收入”。收入按每条最终成功短信的`billingUnits × unitPrice`发送时快照逐条计算后汇总，失败和未知短信不计收入；不再以`SmsBillingRecord.billingStatus=charged/refunded`决定利润报表收入。不同历史单价必须分别计算，不能使用当前应用单价倒算。
 - 通道维度继续仅将收入归属到短信最终提交所在通道，避免补发链路在多个通道重复计收；成本仍按各次提交的通道成本单价快照乘以成功分片数，利润=收入-成本，综合利润率=合计利润/合计收入。
@@ -3483,7 +3490,7 @@ git diff --check
 - 报表专项9/9、API全量35个suite/450项通过；前端TypeScript、API TypeScript正式构建及Vite 8.1.5生产构建通过，Vite仅保留既有大chunk提示。依赖包装器因既有`msgpackr-extract`构建脚本未审批而未用于验证，改为直接调用已安装的本地Jest、TypeScript和Vite入口，未修改依赖审批或供应链配置。
 - 本轮未提交、未推送、未部署，未连接或修改预生产数据，未发送、补发或重投短信。受保护的`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续不删除、不提交、不归因于本需求；依赖包装器临时生成的`pnpm-lock.yaml`已精确移除。

-## 2026-08-12 热力图观察期、登录动画与金额样式（待发布）
+## 2026-08-12 热力图观察期、登录动画与金额样式（历史开发记录，已随 `0cd3534` 发布）

 - 修复签名报备通过后完整观察窗口内不生成快照的问题：04:00检测现在按T-1自然日保存单日提交、受理和成功量，观察期状态为`observing`，不创建预警周期、站内消息或Webhook；观察期结束后仍使用配置的15/30天窗口累计量判断预警。热力图将检测日映射到T-1活动日，每行增加30日受理短信合计并按合计降序排序。
 - 企业签名管理列表中的企业、企业应用名称改为常规400字重；签名名称和状态层级不变。客户端登录页增加纯展示Canvas粒子连线动画，Canvas不接收点击、不读取输入，组件卸载时取消动画帧，系统减少动态效果或页面隐藏时停止位移。