feat: add reconciliation and quality reporting

docs/system-functional-test-cases.md

@@ -328,12 +328,14 @@
 - 前置条件：存在两个 active 通道、一个包含这两个通道的通道组，以及绑定该通道组的企业应用。
 - 步骤：
   1. 在报备字段库创建图片字段“营业执照”和字符串字段“网站主体”，并直接调用 API 尝试创建整数、网址、电话、日期等其他类型。
-  2. 在通道一将营业执照配置为签名报备必填，在通道二将同一字段配置为两者共用非必填，并将网站主体配置为引流信息报备必填。
-  3. 打开该企业应用下的企业签名编辑弹窗和引流信息编辑弹窗。
+  2. 将营业执照配置为通用签名报备必填，将网站主体配置为通用引流信息报备必填；再在通道一选择同一个营业执照字段配置为签名报备，在通道二配置其他通道专用字段。
+  3. 分别打开绑定应用和不绑定应用的企业签名添加/编辑弹窗，以及对应引流信息添加/编辑弹窗；同时在客户端执行新增签名和新增/修改引流信息。
   4. 分别尝试缺少必填值保存，再补齐文件和值后保存。
   5. 查询 PostgreSQL 中签名、签名报备材料和引流报备材料记录；删除该引流项后再次查询。
 - 预期结果：
-  - 营业执照按字段库 ID 合并为一个字段，且因任一目标通道必填而整体必填；签名弹窗展示营业执照，引流弹窗展示网站主体及两者共用字段。
+  - 通用字段和通道字段按字段库 ID 合并去重；营业执照在所有签名添加/编辑表单中出现，网站主体在所有引流信息添加/编辑表单中出现，不绑定应用也不能绕过通用必填校验。
+  - 企业签名弹窗不再展示固定签名依据、资质凭证、企业信息和责任人信息；资料全部来自动态配置。
+  - 通用字段仍可在通道报备字段选择器中选中；删除通用配置不删除字段定义和历史资料，字段仍被通道或通用配置引用时禁止删除字段定义。
 
 ### TC-ADMIN-005B 引流信息按通道报备及三入口同步
 
@@ -3259,6 +3261,20 @@ npm run verify:phase8
 | TC-BILLING-013 | 准备已提交扣费但 72 小时完全无回执的 `submitted` 短信，以及有 `UNKNOWN` 回执且超过 72 小时的短信；启动 API 定时扫描并模拟重复扫描。 | 两类短信都转为 timeout 并退款；任务进度刷新；同一短信只退款一次；定时扫描默认启用且每 5 分钟执行。 |
 | TC-SEC-006 | 安装 API 生产依赖并执行 `npm audit`；使用缺文件、多文件、超大文件、超量字段和正常单文件调用认证后的 multipart 上传接口。 | NestJS/Multer/Hono 已升级或锁定到修复版本，生产依赖 audit 为 0；接口只接受一个不超过 20MB 的文件，并限制字段、part、字段名、字段值和 header pair 数量；异常请求返回受控 4xx，正常文件仍写入真实 MinIO 和 `FileObject`。 |
 
+### 17.5.1 报表对账细化
+
+| 用例 | 细化执行点 | 必查断言 |
+| --- | --- | --- |
+| TC-REPORT-001 | 在同一发送日准备多个企业和应用的单条、长短信，覆盖 delivered、failed、unknown；次日执行报表刷新并按日期、企业、应用查询对账单。 | 只生成 T-1 及更早完整日期；发送和成功均按 `billingUnits` 汇总；成功只包含最终 delivered；企业与应用隔离正确；API 使用 PostgreSQL 报表表和服务端分页。 |
+| TC-REPORT-002 | 准备已扣费成功、最终失败退款、同通道成功和跨通道补发成功短信，分别按企业应用和通道查看利润报表。 | 企业应用消费只包含 charged；退款不算收入；所有 accepted 尝试均按成本快照计入成本；通道维度收入只归属最终提交且不重复；利润=消费-成本，利润率计算正确，收入为 0 时显示 0%。 |
+| 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 数据。 |
+| TC-QUALITY-001 | 为同一日期、同一维度准备 100 条 delivered 短信，构造不同的 `submittedAt/deliveredAt`，其中最慢 5 条显著偏大。 | 发送量和成功量按 billingUnits 汇总；成功率精确；平均到达时长先按组计算 P95，只平均小于等于 P95 的样本，最慢 5% 不进入均值；无有效成功时间时返回空值。 |
+| TC-QUALITY-002 | 分别准备多个企业应用、通道、签名和引流信息的短信，并制造 accepted 补发及不同 Gateway 回执。 | 四个 Tab 分组正确；通道只使用对应 submit/receipt；每个 Tab 服务端按 sentUnits 降序，相同数量再按日期和名称稳定排序；T-4～T-1 重算同步更新四类质量行。 |
+| TC-QUALITY-003 | 同一签名配置短 URL、包含短 URL 的长 URL、两个同长度 URL；发送正文分别命中长 URL、唯一 URL、同长度歧义和完全未命中，再对历史记录执行 migration。 | 新短信与历史短信都优先关联唯一最长 approved URL；歧义和未命中不写伪造 ID 并归入“未关联引流信息”；每条短信在引流维度只统计一次。 |
+| TC-QUALITY-004 | 打开“发送质量报表”，依次切换企业应用、通道、签名、引流信息 Tab，使用日期、企业、应用、通道筛选并翻页。 | 菜单位于“报表对账”下；页面调用真实 `/admin/reports/quality`；展示发送量、成功量、成功率、P95 截尾平均时长和生成时间，不使用前端明细聚合。 |
+
 ### 17.6 系统日志细化
 
 | 用例 | 细化执行点 | 必查断言 |