feat: complete reporting and filing workflows

docs/first-version-development-requirements.md

@@ -303,7 +303,7 @@
 - 已实现下游恢复控制第一版：Gateway 对恢复候选账号增加账号级恢复锁、失败/等待连接退避和恢复状态持久化，避免同一账号被并发重复恢复或每轮高频空转；控制面新增 `GET /downstream/recovery-statuses` 可查看最近一次恢复状态、重试次数、下一次可恢复时间和错误原因。
 - 已实现下游恢复观测第一版：控制面新增 `GET /downstream/recovery-overview`，一次性返回恢复候选账号与恢复状态，便于联调和生产排查。
 - 已实现下游恢复状态回流第一版：Gateway 在每次恢复状态变化后，调用 NestJS `/api/gateway/events/downstream/recovery-status` 真实回传账号恢复状态；NestJS 将状态写入 Prisma/PostgreSQL `GatewayDownstreamRecoveryStatus`。
-- 已实现下游恢复状态运营化第一版：运营端新增独立“恢复状态管理”页面，支持真实列表、分页、详情查看和当前筛选结果 CSV 导出；原“下游投递记录”页面只保留投递记录本身，不再混放恢复状态区块。
+- 已实现下游恢复状态运营化第一版：运营端新增独立“恢复状态管理”页面，明确说明该页用于观察客户重连或 Gateway 重启后的未完成下游投递恢复，每个账号展示当前或最近一次恢复状态；支持按最近更新时间筛选（默认近 7 天）、真实列表、分页、详情查看和当前筛选结果 CSV 导出。原“下游投递记录”页面只保留逐条投递记录并默认查询近 7 天，不再混放恢复状态区块。
 - 已实现下游恢复失败分类第一版：Gateway/NestJS 共同维护 `failureCategory`，覆盖 `client_disconnected`、`backoff`、`lock_contended`、`lock_lost`、`flush_failed`、`partial_delivery_failed`、`unknown`；运营端“恢复状态管理”页面支持失败分类筛选、分类分布统计、详情展示和导出字段。
 - 已实现多 Gateway 恢复抢占协调第一版：恢复锁从单纯实例名升级为 Redis token 租约，状态记录 `lockOwner/lockExpiresAt`；恢复完成时必须通过 Lua 原子校验锁 token，只有持锁实例才能写入最终恢复状态并释放锁，避免旧实例超时后误删新实例锁或覆盖新实例恢复结果；运营端详情/列表可查看锁持有实例。
 - 已实现长短信分片审计第一版：Gateway `SubmitResult` 回传真实 `segments[]`，包含 `segmentTotal/segmentIndex/sequenceId/gatewayMessageId/submitStatus/submittedAt`；NestJS 写入 Prisma/PostgreSQL `SmsMessageSegmentAudit`，回执按 `gatewayMessageId` 回填分片回执状态，补偿归因可记录 `compensationType`；运营端短信记录详情可查看真实分片提交、回执和补偿审计。
@@ -555,8 +555,8 @@
 - 在“数据详单”之后增加“报表对账”一级菜单，包含“对账单”和“利润报表”两个二级菜单；页面必须读取真实 NestJS API 与 PostgreSQL 报表表，不得在前端按明细临时拼接或使用静态数据。
 - 对账单按发送日期、企业、企业应用汇总日发送条数和成功条数。发送条数、成功条数均按短信计费条数 `billingUnits` 统计，成功以最终 `delivered` 状态为准。
 - 利润报表按发送日期汇总日发送条数、成功条数、消费金额、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。
-- 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额统计该应用短信所有上游 `accepted` 提交的通道成本，包括补发产生的真实额外成本。
-- 通道维度按实际上游 `accepted` 提交统计发送量和成本，按同一 Gateway 消息回执统计成功量；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价和成本金额必须在提交记录创建时快照，后续修改通道单价不得改写历史成本。
+- 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额按每次真实提交的通道成本单价快照乘以该次提交最终成功的短信分片数计算。补发只有产生成功分片时才增加对应通道成本，失败、未知或尚未收到成功回执的分片不计成本。
+- 通道维度按实际上游 `accepted` 提交统计发送量，按分片回执统计成功量和成本；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价必须在提交记录创建时快照，后续修改通道单价不得改写历史成本；历史缺少分片审计但存在明确成功回执时，才按该次短信计费分片数兼容计算。
 - 利润等于消费金额减成本金额；利润率等于利润除以消费金额，消费金额为 0 时利润率按 0 展示。所有金额使用 `0.0001 元`整数金额单位持久化并按四位小数展示。
 - 报表按北京时间 T+1 生成，不生成当天未完整数据；每日刷新时必须在同一事务内重新生成 T-4 至 T-1 四个完整自然日，使 72 小时内到达或变化的回执能够修正发送成功和利润结果。
 - API 启动后自动补生成最近四个完整自然日，并按日执行滚动刷新；报表查询支持服务端日期、企业、应用、通道和维度过滤及分页。
@@ -1506,6 +1506,12 @@
 4. 创建批次时按每条资料所属企业应用的当前生效路由规则展开所有通道；一个签名走多个通道时，必须为每个通道创建或重置独立报备任务并生成一份该通道的 `.xlsx`。无生效路由、通道未配置字段或缺少通道必填资料时，该资料继续保留在待报备池，任务进入“资料待补充”，不得伪装为已完成。
 5. 通道“配置签名报备字段”和“配置引流信息字段”弹窗使用字段池，按资料类型分别配置。每列包含标准字段、通道导出表头、列顺序、必填、说明、列宽、文本转换、缺省值以及图片宽高；导出表头和列顺序必须严格使用通道配置，不受导入表格原始名称和顺序影响。
 6. 通道导出文件必须为 WPS/Excel 可打开的 `.xlsx`，图片直接内嵌到对应单元格区域，而不是仅写 MinIO URL 或本地路径。批次保留所选材料版本快照、通道文件、行号和通道任务关联，可从最近批次直接下载每个通道文件。
+7. 2026-07-28 起，导入“确认”只把每一行保存为待审核明细，不得立即创建、修改或自动审核通过签名/引流信息。签名和引流审核中心分别提供“导入批次审核”页签，可查看整批行明细，一次通过全部、通过勾选项或驳回勾选项；审核通过后才将该行应用到真实业务对象并进入正常待报备流程，行校验失败不得阻断同批其他行。
+8. 导入审核必须同时支持新增和修改：页面明确展示每行操作类型、原对象、目标资料、错误原因和审核结果。驳回原因可选，不得因未填写原因阻止常用批量操作；审核人、审核时间和实际处理结果必须落 PostgreSQL。
+9. “待生成报备批次”页面由“待生成资料”和“已生成批次”两个页签组成。两个页签均使用后端分页，并可按关键字和时间范围查询；待生成资料可继续按签名/引流类型筛选。
+10. 已生成批次展示报备总数、成功数和成功率。报备总数以批次导出文件中的通道报备明细数为准，成功数以对应通道报备任务当前为通过的明细数为准；不展示“已导入回执”“等待回执”等当前无明确业务需求的字段。
+11. 报备明细是一条签名或引流信息在一个具体通道上的当前报备状态。常用操作为逐条人工修改状态，弹窗只要求选择目标状态，修改原因可选；详情展示所属企业/应用、来源批次、导出文件行号和时间顺序的状态轨迹。
+12. 本阶段不提供新的回执导入入口，不实现批量回执文件规范、解析或自动状态覆盖。已有历史数据和后端兼容代码保留以便追溯，后续只有在回执文件格式、匹配键、批量结果语义和异常处理规则明确后再立项。
 ## HTTP 客户接口第一版
 
 ### 管理端企业应用配置
@@ -1703,6 +1709,7 @@
 ## 2026-07-26 企业应用停用与回执清算补充要求
 
 - 删除企业前必须检查其企业应用；只要存在`active`或`disabling`应用就阻止删除，并提示先完成应用停用。
+- 删除企业前还必须在企业账户事务锁内检查真实余额；余额大于或小于 0 均禁止删除，并提示“完成余额清算后方可删除，请给企业充值到金额为0”。只有余额恰好为 0 且不存在启用或停用中的企业应用时才允许逻辑删除，避免删除检查与并发充值、扣费或退款竞争。
 - 点击停用应用时，系统必须统计尚未收到供应商回执的短信、待发送回执、等待`CMPP_DELIVER_RESP`的回执、仍可重试的失败投递及待投递上行。
 - 无待清算数据时，应用直接转为`disabled`并断开该账号的全部下游CMPP连接；存在待清算数据时，运营可选择“等待回执后停用”或“强制停用并断开连接”。
 - “等待回执后停用”将应用转为`disabling`：立即拒绝新短信Submit，但保留或允许下游账号重新连接以接收历史回执；待清算数据归零后自动停用。
@@ -1770,3 +1777,24 @@
 5. 通道测试短信处于回执等待状态时与普通短信使用相同状态样式，不得因“测试短信”说明显示红色失败；发送测试弹窗的接入号和网关密码必须使用独立表单名称及自动填充语义，避免密码管理器串填。
 6. 企业应用的通道组选择控件不得突破卡片宽度；通用输入控件在有无提示文案时控制区顶部对齐。
 7. 分片补偿审计按`createdAt`从早到晚展示，并显示审计时间；同一时刻按分片序号和主键稳定排序。
+
+## 2026-07-28 运营端列表与审核详情补充要求
+
+1. 报备字段库的“被通道引用”只统计仍未删除的通道，并按不同通道去重；已删除通道的历史映射不再阻止字段删除。
+2. 通道报备详情只展示仍未删除的企业签名；已删除签名的历史报备记录继续保留在数据库审计链路中，但不进入当前业务列表。
+3. 运营看板“今日企业消费”只排行仍未删除的企业；消费金额继续按北京时间当天真实已计费短信聚合。
+4. 短信审核列表展示发送企业和企业应用，不展示审核任务号和审核原因；任务号、原因及号码明细保留在详情和查询能力中。
+5. 短信任务进度的号码数量提供“查看列表”入口，号码弹窗必须从真实短信记录服务端分页和搜索，并展示手机号、归属地、运营商和短信状态。
+6. 运营端企业签名的引流资料只保留“引流url或号码”业务字段，不再要求填写独立“引流信息”；新增和编辑均以该字段作为真实保存与检索值。
+7. 审核中心各审核页面的查看入口统一命名为“详情”；详情必须展示审核时间和审核人员用户名。运营自动通过显示“系统自动”，无法追溯审核人的历史记录显示“-”，不得伪造人员。
+8. 企业管理列表不展示实现来源类注释，不向运营人员暴露“数据来自真实接口”等研发说明。
+## 数据统计：签名在通道与运营商维度的发送质量
+
+- 数据统计页默认查询北京时间当天，并允许选择任意一个不晚于今天的自然日。
+- 仅统计短信记录已关联平台签名的记录；正文中出现但企业未在平台登记、未形成`signatureId`关联的签名不纳入本统计。
+- 签名总览按业务短信记录统计发送量、送达成功、送达失败、提交失败、成功率和平均到达时间；同一业务短信在总览中只计算一次。
+- 签名通道明细按真实`SmsSubmitRecord`提交尝试统计。短信发生切换通道补发时，各次提交分别归入实际通道，因此通道提交次数允许大于业务短信数。
+- 运营商取短信发送时识别并持久化的真实号码运营商；通道与运营商是实际发送组合，不假设一个通道只支持一个运营商，也不把通道永久挂在某一个运营商下。
+- 查看签名明细时使用“通道行 × 运营商列”矩阵，每个有数据的单元格展示提交次数、成功率、平均到达时间及提交失败数量；所选日期无真实提交显示`—`，不据此推断通道不支持该运营商。
+- 平均到达时间只统计成功送达的提交尝试，从该通道提交受理时间开始，到该通道成功回执完成为止；长短信以全部成功分片完成时间为准。
+- 签名列表提供签名、企业或应用关键字查询和后端分页；查看详情不应依赖前端模拟数据或浏览器本地存储。