feat: 优化签名热力图与金额展示

2026-08-12 11:41:47 +08:00
parent e64b5e23fe
commit 0cd353450a
33 changed files with 344 additions and 121 deletions
@@ -559,7 +559,7 @@

 - 在“数据详单”之后增加“报表对账”一级菜单，包含“对账单”和“利润报表”两个二级菜单；页面必须读取真实 NestJS API 与 PostgreSQL 报表表，不得在前端按明细临时拼接或使用静态数据。
 - 对账单按发送日期、企业、企业应用汇总日发送条数和成功条数。发送条数、成功条数均按短信计费条数 `billingUnits` 统计，成功以最终 `delivered` 状态为准。
- 利润报表按发送日期汇总日发送条数、成功条数、消费金额、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。
+- 利润报表按发送日期汇总日发送条数、成功条数、收入、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。收入必须逐条按“最终成功计费条数 × 该短信发送时的客户单价快照”计算后汇总，不能按当前应用单价倒算；退款状态不改变该成功收入口径。通道维度只将收入归属到短信最终提交所在通道，补发链路不得重复计算收入。利润报表页面、筛选结果汇总和 CSV 不展示返还数据。
 - 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额按每次真实提交的通道成本单价快照乘以该次提交最终成功的短信分片数计算。补发只有产生成功分片时才增加对应通道成本，失败、未知或尚未收到成功回执的分片不计成本。
 - 通道维度按实际上游 `accepted` 提交统计发送量，按分片回执统计成功量和成本；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价必须在提交记录创建时快照，后续修改通道单价不得改写历史成本；历史缺少分片审计但存在明确成功回执时，才按该次短信计费分片数兼容计算。
 - 利润等于消费金额减成本金额；利润率等于利润除以消费金额，消费金额为 0 时利润率按 0 展示。所有金额使用 `0.0001 元`整数金额单位持久化并按四位小数展示。
@@ -570,6 +570,7 @@
 - 平均到达时长只使用成功且时间有效的短信，按 `deliveredAt - submittedAt` 计算；每个日期、每个维度组先计算 P95，剔除大于 P95 的最慢 5% 样本后再求平均。无成功或无有效时间样本时展示为空，不以 0 冒充。
 - `SmsMessageRecord` 必须固化实际使用的 `drainageInfoId`。新短信在同签名已审核通过的引流信息中按正文精确包含 URL 匹配，优先最长 URL；最长 URL 出现多个同长度候选时视为歧义并不关联。历史短信使用同一规则回填，未命中或歧义统一归入“未关联引流信息”，不得把一条短信复制到签名下所有引流信息造成重复统计。
 - 发送质量报表与对账、利润报表共用 T+1 及 T-4 至 T-1 滚动重算任务，每次重算在同一日期事务内重建四个质量维度。
+- 签名活跃度热力图每天均记录已报备维度的单日真实提交尝试、上游受理业务短信和最终成功业务短信；报备通过后尚未满足完整观察窗口时状态为“观察中”，仍生成热力图快照但不产生预警消息或 Webhook。热力图每行展示 T-1 至 T-30 的上游受理业务短信合计，并按合计从大到小排序；观察窗口只控制是否预警，不得隐藏真实发送数据。
 - 对账单、利润报表、发送质量报表均提供导出功能。导出必须由真实 API 按页面当前筛选条件查询完整结果并生成 CSV，不得只导出当前分页或在浏览器内拼接静态数据。
 - 报备字段库采用自适应卡片布局，分开展示统计概览、签名/引流信息通用字段和字段定义；卡片明确展示通道引用数及通用配置数，已被引用的字段不可删除。
 - 运营端和客户端用户管理页的新增用户按钮使用标准小尺寸操作按钮，不得占用大块页面空间。
@@ -1558,11 +1559,12 @@

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

-1. 企业应用客户单价、通道成本单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数，页面及导出文件统一展示 4 位小数。
+1. 企业应用客户单价、通道成本单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数，页面及导出文件统一展示 4 位小数。利润报表中的收入同样固定展示 4 位小数。
 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 等纯文本载体保持原始数值格式，不拆分字符。

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

@@ -1959,7 +1961,7 @@
 ## 报表筛选结果全量汇总（2026-08-09）

 - 对账单、利润报表和发送质量报表在每次搜索后都必须展示当前筛选条件匹配的全部结果汇总，不得只对当前分页明细在前端求和。汇总、总数、分页和CSV导出必须复用同一套日期、企业、应用、通道及统计维度筛选口径。
- 三类报表均汇总提交、发送、未知、成功和失败条数；利润报表另汇总净消费、返还、成本和利润金额。综合成功率必须按合计成功量/合计发送量重算，综合利润率必须按合计利润/合计净消费重算，不得对每行百分比求和或简单平均；分母为0时显示0%。
+- 三类报表均汇总提交、发送、未知、成功和失败条数；利润报表另汇总收入、成本和利润金额，不展示返还明细或返还合计。综合成功率必须按合计成功量/合计发送量重算，综合利润率必须按合计利润/合计收入重算，不得对每行百分比求和或简单平均；分母为0时显示0%。
 - 平均到达时长不属于可加总数据，本汇总区不对各日、各维度均值再求和；明细表仍保留每组的真实P95截尾平均到达时长。

 ## 新建企业省份与地市字典（2026-08-09）
@@ -169,7 +169,7 @@

 预警页签命名为“预警消息”，后端按消息创建时间的北京时间日期区间查询历史消息，并在同一查询中关联检测维度、企业、企业应用、签名和通道完成筛选、计数及每页10条分页；默认区间为今日至今日。抑制和取消抑制复用平台`Modal`，临时抑制以截止日期换算为后端天数，永久抑制不传天数，两者均要求原因；取消也要求原因，不使用浏览器原生弹窗。

-热力图日期列按`T-1`至`T-30`由新到旧排列；行首只常驻签名以及通道维度必要的通道/运营商标识，企业和企业应用通过签名悬停提示查看。企业、通道模块分别在前端对后端返回的真实维度按企业、企业应用、签名过滤并独立分页。格子悬停明确展示提交条数和最终发送成功条数，不混淆上游接受。
+热力图日期列按`T-1`至`T-30`由新到旧排列；行首只常驻签名以及通道维度必要的通道/运营商标识，企业和企业应用通过签名悬停提示查看。企业、通道模块分别在前端对后端返回的真实维度按企业、企业应用、签名过滤并独立分页。每行增加30日上游受理业务短信合计并按合计降序排列。格子悬停明确展示提交条数和最终发送成功条数，不混淆上游接受。报备后的完整观察窗口只控制清退预警资格，观察期仍按日生成`observing`快照并展示真实发送量，不创建预警周期、站内消息或Webhook。

 页面底部增加独立的未报备签名查询。后端按所选北京时间自然日，以`SmsMessageRecord`为业务短信事实，按短信运营商检查该签名是否存在任一未删除通道上的当前运营商级`approved`任务；仍处于`approved`的历史通道级兼容任务视为已有真实旧报备，避免迁移期误报。其余按签名和消息实际企业应用聚合，后端完成关键字过滤、总数和分页，前端不使用静态数据或全量拉取伪分页。

@@ -3456,7 +3456,7 @@ npm run verify:phase8
 | 用例 | 细化执行点 | 必查断言 |
 | --- | --- | --- |
 | TC-REPORT-001 | 在同一发送日准备多个企业和应用的单条、长短信，覆盖 delivered、failed、unknown；次日执行报表刷新并按日期、企业、应用查询对账单。 | 只生成 T-1 及更早完整日期；发送和成功均按 `billingUnits` 汇总；成功只包含最终 delivered；企业与应用隔离正确；API 使用 PostgreSQL 报表表和服务端分页。 |
-| TC-REPORT-002 | 准备短短信成功、三分片长短信仅两片成功、最终失败退款、同通道成功和跨通道补发成功短信，分别按企业应用和通道查看利润报表。 | 企业应用消费只包含 charged；退款不算收入；成本严格等于各次提交的通道成本单价快照乘以该次成功分片数，失败和未知分片成本为0；通道维度收入只归属最终提交且不重复；利润=消费-成本，利润率计算正确，收入为0时显示0%。 |
+| TC-REPORT-002 | 准备不同客户单价的短短信成功、三分片长短信仅两片成功、最终失败退款、同通道成功和跨通道补发成功短信，分别按企业应用和通道查看利润报表。 | 收入逐条等于最终成功计费条数×该短信发送时的客户单价快照后汇总，不受 charged/refunded 状态切换影响；失败和未知短信不计收入；成本严格等于各次提交的通道成本单价快照乘以该次成功分片数，失败和未知分片成本为0；通道维度收入只归属最终提交且不重复；利润=收入-成本，利润率计算正确，收入为0时显示0%；页面、汇总与 CSV 均无返还字段。 |
 | TC-REPORT-003 | 首次生成后，在 T-3 短信上补录 delivered 回执并将另一条 T-2 短信最终失败退款，再执行次日定时刷新。 | 每次刷新准确覆盖 T-4、T-3、T-2、T-1；对应日期旧行在事务内重建，成功数、消费、利润同步修正；T-5 及更早报表不被本次任务改写。 |
 | TC-REPORT-004 | 先按成本价发送并 accepted，再修改通道单价，随后生成和重复刷新报表。 | `SmsSubmitRecord.costUnitPrice/costAmountCents` 保存提交时快照；历史成本不随通道当前单价变化；新提交使用新单价。 |
 | TC-REPORT-005 | 打开运营端菜单和两张报表，切换日期、企业、应用及通道维度并翻页。 | “报表对账”位于“数据详单”之后且包含两个二级菜单；筛选和分页调用真实 `/admin/reports/*` API；页面展示生成时间及 T+1/T-4～T-1 口径，不使用 mock、静态数组或 localStorage 数据。 |
@@ -3650,7 +3650,7 @@ npm run verify:phase8
 | TC-MONEY-001 | 运营端编辑企业应用，将客户单价填写为 `0.0325` 并保存，刷新列表后再次进入编辑页。 | 保存调用真实 NestJS API；数据库 `SmsApplication.customerUnitPrice=325`；列表和编辑页均展示 `0.0325`，不被舍入为 `0.03`。 |
 | TC-MONEY-002 | 使用单价 `0.0325` 的应用发送 2 个计费条数。 | 预估、冻结及最终计费金额均为 `650` 金额单位，即 `0.0650 元`；返还时按相同精度原额冲回。 |
 | TC-MONEY-003 | 分别设置余额、授信、充值、今日消费和今日返还为含 4 位小数的金额，查看运营端企业列表、详情、首页以及客户端首页和账单。 | 所有位置展示同一真实金额且固定为 4 位小数，不使用浮点累计或仅保留到分。 |
-| TC-MONEY-004 | 打开短信详单、对账单、利润报表并导出 CSV。 | 消费金额、成本金额和利润均按 4 位小数显示；CSV 表头以“元”为单位，值固定 4 位小数，汇总结果与数据库整数金额单位一致。 |
+| TC-MONEY-004 | 打开短信详单、对账单、利润报表并导出 CSV。 | 短信详单消费金额以及利润报表收入、成本和利润均按 4 位小数显示；CSV 表头以“元”为单位，值固定 4 位小数，汇总结果与数据库整数金额单位一致。 |
 | TC-MONEY-005 | 在迁移前备份数据库并记录各金额列汇总，执行四位精度迁移后复核字段类型及汇总。 | 金额列升级为 `BIGINT`；迁移后整数汇总等于迁移前的 100 倍，按新除数换算后的人民币金额完全相等。 |
 | TC-MONEY-006 | 在单价、授信和充值输入中分别填写超过 4 位小数、非法字符和超出 JavaScript 安全整数范围的值。 | 前后端拒绝无效值并返回可读错误；API 不静默舍入或输出已失真的金额。 |
 | TC-IF-PARAM-001 | 运营端分别打开已开通 CMPP、HTTP 的企业应用参数弹窗并一键复制；模拟 Clipboard API 在 HTTP 页面被拒绝。 | CMPP 内容展示平台公网地址和端口而非上游通道地址；HTTP 内容包含应用、能力、QPS、白名单、投递模式和文档地址；降级复制成功且有明确提示。 |
@@ -4475,7 +4475,7 @@ npm run verify:phase8
 | 用例编号 | 操作 | 预期结果 |
 | --- | --- | --- |
 | TC-REPORT-SUMMARY-001 | 在对账单准备超过一页的多日、多企业应用数据，分别按日期、企业和应用搜索并翻页 | 顶部提交、发送、未知、成功、失败合计等于PostgreSQL中全部筛选结果；翻页不改变汇总，改变筛选条件后同步刷新 |
-| TC-REPORT-SUMMARY-002 | 在利润报表分别选择企业应用和通道维度，准备多行金额且至少一行收入为0 | 量类与金额类均按完整筛选结果求和；综合利润率=合计利润/合计净消费，不是行利润率求和或平均，合计收入为0时为0% |
+| TC-REPORT-SUMMARY-002 | 在利润报表分别选择企业应用和通道维度，准备多行金额且至少一行收入为0 | 量类与金额类均按完整筛选结果求和；只展示收入、成本和利润金额合计，不展示返还合计；综合利润率=合计利润/合计收入，不是行利润率求和或平均，合计收入为0时为0% |
 | TC-REPORT-SUMMARY-003 | 在发送质量报表的企业应用、通道、签名、引流信息四个Tab分别搜索和翻页 | 汇总条数来自真实后端全量聚合；综合成功率=合计成功/合计发送，不累加或平均各行成功率；汇总区不对平均到达时长求和 |
 | TC-REPORT-SUMMARY-004 | 调用三个报表列表API，对比`items`当前页、`total`、`summary`和相同条件CSV | `summary`与CSV完整结果口径一致且不受`page/pageSize`影响；无匹配数据时所有合计和综合率均为0 |

@@ -4541,6 +4541,11 @@ npm run verify:phase8
 | TC-SIGNATURE-RETIREMENT-016 | 检查顶部任务入口和预警入口 | 原待审核入口改为任务图标但计数、弹层和跳转完整；新增预警铃铛进入预警列表，两个计数互不混用 |
 | TC-SIGNATURE-RETIREMENT-017 | 分别在北京时间04:00前后、08:00前后运行自动任务，并模拟服务跨过两个时点后重启 | 04:00只生成幂等检测快照且冻结规则版本和消息正文，不产生站内消息/Webhook；08:00才幂等创建站内消息并生成Webhook投递；晚启动按时点顺序补偿且不重复；页面和管理API均不存在手动检测入口 |
 | TC-SIGNATURE-RETIREMENT-018 | 打开签名质量检测页，并分别翻动企业、通道热力图 | “签名通道发送质量”位于两张热力图之前；两张热力图各按10个维度分页，页码相互独立，翻页不改变另一张页码，30日列仍可横向滚动且数据与真实API一致 |
+| TC-SIGNATURE-RETIREMENT-019 | 签名刚报备通过、尚未满足观察窗口，次日有真实发送数据并执行04:00检测 | 生成状态为“观察中”的单日检测快照，热力图展示真实受理条数，但不创建预警周期、站内消息或Webhook；满足观察窗口后才按窗口累计量判断预警 |
+| TC-SIGNATURE-RETIREMENT-020 | 准备多个签名维度的T-1至T-30快照且合计不同，打开企业和通道热力图 | 每行展示30日受理短信合计，按合计降序排列；分页基于排序后的结果，单元格仍展示各自然日数据 |
+| TC-UI-MONEY-001 | 遍历运营端和客户端包含余额、单价、消费、返还、充值、成本、收入和利润的页面 | 只读金额整数部分沿用主文字颜色，小数点及小数部分使用统一淡色；负号、币种符号和单位位置正确，输入框、复制值和CSV仍为完整纯文本数值 |
+| TC-CLIENT-LOGIN-ANIMATION-001 | 打开客户端登录页并保持页面可见，再切换后台或启用减少动态效果 | Canvas动画在登录框背景平滑运行、不遮挡表单、不响应敏感输入；页面隐藏或组件卸载时停止帧循环，减少动态效果下显示静态背景 |
+| TC-ENTERPRISE-SIGNATURE-STYLE-001 | 打开企业签名管理列表 | 企业名称和企业应用名称使用常规字重，签名名称及状态层级保持原样 |
 | TC-SIGNATURE-RETIREMENT-019 | 检查两张热力图日期、行首和悬停信息 | 日期从左到右为`T-1`至`T-30`；行首不常驻企业和企业应用，悬停签名可看到企业、企业应用；通道维度仍能识别通道和运营商 |
 | TC-SIGNATURE-RETIREMENT-020 | 分别在企业、通道热力图搜索企业、企业应用、签名并清空 | 每张热力图只过滤自身真实维度并回到第一页；三类关键字均可命中，清空恢复，另一张热力图的关键字和页码不变 |
 | TC-SIGNATURE-RETIREMENT-021 | 悬停报备前、无快照、零量和非零量格子 | 报备前显示不适用；无快照说明当日无检测；真实快照明确显示提交条数、上游接受条数、发送成功条数和成功率，发送成功等于真实最终送达而非受理成功 |
@@ -3463,3 +3463,20 @@ git diff --check
 - 发布前有61条`legacy_channel`任务和64个缺失运营商目标；发布后`legacy_channel=0`，新增`legacy_carrier_auto_split=64`和`legacy_scope_auto_split=61`条migration轨迹。16条由历史已通过任务新建的运营商任务`approvedAt`统一为北京时间`2026-08-10 22:56:14.239`且空值为0；原有运营商级任务未覆盖，历史任务全部保留为`legacy_split`。
 - 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 利润报表收入口径调整（未提交、未发布）
+
+- 利润报表“净消费”统一更名为“收入”。收入按每条最终成功短信的`billingUnits × unitPrice`发送时快照逐条计算后汇总，失败和未知短信不计收入；不再以`SmsBillingRecord.billingStatus=charged/refunded`决定利润报表收入。不同历史单价必须分别计算，不能使用当前应用单价倒算。
+- 通道维度继续仅将收入归属到短信最终提交所在通道，避免补发链路在多个通道重复计收；成本仍按各次提交的通道成本单价快照乘以成功分片数，利润=收入-成本，综合利润率=合计利润/合计收入。
+- 页面明细、筛选结果汇总、前端类型、列表API和CSV均移除返还数据；CSV表头改为“收入金额(元)”。数据库`DailyProfitReport.refundCents`暂时保留作既有数据和回滚兼容，新重算快照统一写0，不执行破坏性migration。
+- 本地PostgreSQL和Redis恢复后，使用正式`ReportsService`成功重算2026-08-08至2026-08-11。独立SQL按应用逐条复核`成功计费条数 × 客户单价快照`，与报表收入差异0条，重算行`refundCents`非0差异0条；本地现有成功样本单价均为0，非零及混合单价场景由专项自动化断言覆盖，未伪造数据库样本。
+- 报表专项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 热力图观察期、登录动画与金额样式（待发布）
+
+- 修复签名报备通过后完整观察窗口内不生成快照的问题：04:00检测现在按T-1自然日保存单日提交、受理和成功量，观察期状态为`observing`，不创建预警周期、站内消息或Webhook；观察期结束后仍使用配置的15/30天窗口累计量判断预警。热力图将检测日映射到T-1活动日，每行增加30日受理短信合计并按合计降序排序。
+- 企业签名管理列表中的企业、企业应用名称改为常规400字重；签名名称和状态层级不变。客户端登录页增加纯展示Canvas粒子连线动画，Canvas不接收点击、不读取输入，组件卸载时取消动画帧，系统减少动态效果或页面隐藏时停止位移。
+- 新增统一`MoneyText`只读金额组件，运营端和客户端现有余额、授信、单价、消费、返还、充值、收入、成本、利润及短信计费等金额，小数点和小数部分使用统一次级文字色；输入框、CSV、复制文本和底层金额值不拆分、不改变。
+- 本地正式`SignatureRetirementService`在真实PostgreSQL执行2026-08-12检测，生成11条alert、2条healthy、6条observing快照；执行前后站内消息均55条、Webhook投递均0条，证明检测阶段不外发。浏览器真实API验收热力图首列为08-11、显示30日合计且合计491/134/65/0按降序，6个观察期格子可见；企业与应用字重为400；金额小数色为`rgb(107, 114, 128)`；客户端登录Canvas为2560×1440并正常绘制，页面控制台error/warn为0。
+- API全量35个suite/451项、签名清退与利润专项18/18项、前后端TypeScript、API正式构建、Vite 8.1.5生产构建、4份Gateway队列契约、Gateway `go test ./...`和`go vet ./...`通过；Vite仅保留既有约2.06MB单chunk提示，`git diff --check`仅有既有LF/CRLF提示。