画布 1
运八
  202607迭代
    安徽运八需求
      平台端-监管上报-上报看板
        tc-P0-功能测试：验证看板按完整运单号精确搜索运单
          pc：1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录
          测试数据：运单号: YB202607130001
          步骤：1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键
            预期：页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001'
          备注：对应TP-A-001
        tc-P0-功能测试：验证看板按运单号模糊搜索匹配多条记录
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003）
          测试数据：运单号部分字符: YB20260713
          步骤：1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索
            预期：页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果
          备注：对应TP-A-001
        tc-P1-功能测试：验证看板按不存在的单号搜索显示空结果
          pc：1. 使用super_admin账号登录管理端
          测试数据：运单号: NOTEXIST999
          步骤：1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索
            预期：页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错
          备注：对应TP-A-001
        tc-P1-功能测试：验证看板按"第一次上报"阶段筛选运单
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单）
          测试数据：筛选条件: 第一次上报
          步骤：1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据
            预期：列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致
          备注：对应TP-A-002
        tc-P1-功能测试：验证看板按"异常"核验状态筛选运单
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单
          测试数据：筛选条件: 核验状态=异常
          步骤：1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据
            预期：列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件
          备注：对应TP-A-003
        tc-P1-功能测试：验证看板按"申诉中"申诉状态筛选运单
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条
          测试数据：筛选条件: 申诉状态=申诉中
          步骤：1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比
            预期：列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件
          备注：对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致
        tc-P1-功能测试：验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索
          pc：1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"）
          测试数据：组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026
          步骤：1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索
            预期：列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字
          备注：对应TP-A-005
        tc-P2-功能测试：验证看板导出当前筛选结果为Excel文件
          pc：1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据
          测试数据：筛选: 第一次上报
          步骤：1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件
            预期：浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时
          备注：对应TP-A-006
        tc-P2-性能测试：验证看板大数据量导出不超时不OOM
          pc：1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录
          测试数据：导出全部数据, 约2000+条
          步骤：1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间
            预期：导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作
          备注：对应TP-A-006
        tc-P2-功能测试：验证看板重置按钮恢复所有查询条件至默认值
          pc：1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026"
          测试数据：重置前条件: 第二次上报+异常+YB2026
          步骤：1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据
            预期：模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询
          备注：对应TP-A-007
        tc-P1-功能测试：验证看板列表展示14个字段且顺序与需求一致
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录
          测试数据：查看运单YB202607130001
          步骤：1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序
            预期：列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined"
          备注：对应TP-A-008
        tc-P2-功能测试：验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常)
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条
          测试数据：运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常
          步骤：1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色
            预期："上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰
          备注：对应TP-A-009
        tc-P1-功能测试：验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮
          pc：1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条
          测试数据：通过运单: YB202607130001; 异常运单: YB202607130002
          步骤：1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮
            预期：核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息
          备注：对应TP-A-010
        tc-P2-功能测试：验证看板详情弹窗—建单信息分组13字段完整
          pc：1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001
          测试数据：运单号: YB202607130001
          步骤：1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段
            预期：建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致
          备注：对应TP-A-011
        tc-P2-功能测试：验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物)
          pc：1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息
          测试数据：运单号: YB202607130001; 司机: 15188888888
          步骤：1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组
            预期：托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-"
          备注：对应TP-A-011
        tc-P3-易用性测试：验证看板空数据状态展示友好占位提示
          pc：1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"）
          测试数据：运单号: ZZZZZZZZZZ
          步骤：1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索
            预期：列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏
          备注：对应TP-A-012
        tc-P3-功能测试：验证看板分页功能—翻页数据不重复不遗漏
          pc：1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条）
          测试数据：每页20条
          步骤：1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数
            预期：第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面）
          备注：对应TP-A-013
        tc-P1-安全性测试：验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板
          pc：1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据
          测试数据：运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888
          步骤：1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口
            预期：super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志
          备注：对应TP-A-014
      平台端-监管上报-第一次上报
        tc-P0-功能测试：验证装货完成后自动触发第一次上报且全部子对象数据完整
          pc：1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息
          测试数据：运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34
          步骤：1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态
            预期：司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空
          备注：对应TP-B-001
        tc-P0-功能测试：验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报
          pc：1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货"
          测试数据：运单号: YB202607130002; 省份代码: 28(云南)
          步骤：1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录
            预期：管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生
          备注：对应TP-B-002
        tc-P0-功能测试：验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发
          pc：1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货"
          测试数据：安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51
          步骤：1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表
            预期：仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34
          备注：对应TP-B-002; TP-B-004
        tc-P1-功能测试：验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示
          pc：1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003
          测试数据：运单号: YB202607130003; 缺失字段: 承运合同编号
          步骤：1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息
            预期：上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传"
          备注：对应TP-B-003
        tc-P1-功能测试：验证第一次上报统一社会信用代码格式校验（非18位时拒绝）
          pc：1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式）
          测试数据：运单号: YB202607130004; 信用代码: 123456(无效)
          步骤：1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志
            预期：上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台
          备注：对应TP-B-003
        tc-P0-功能测试：验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成"
          pc：1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足）
          测试数据：运单号: YB202607130005
          步骤：1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息
            预期：接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P0-功能测试：验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝
          pc：1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成
          测试数据：运单号: YB202607130006
          步骤：1. 通过API直接调用第三次上报接口；2. 查看接口返回
            预期：接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P1-功能测试：验证第一次上报成功后监管平台核验通过时自动调用修改字段接口
          pc：1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过
          测试数据：运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值）
          步骤：1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值
            预期：上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制
          备注：对应TP-B-006
        tc-P1-功能测试：验证第一次上报失败后自动重试最多3次且间隔递增
          pc：1. 运单YB202607130007第一次上报时模拟监管平台返回失败
          测试数据：运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值）
          步骤：1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成
            预期：第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录
          备注：对应TP-B-007
        tc-P1-功能测试：验证第一次上报3次重试全部失败后通知运营人员
          pc：1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信
          测试数据：运单号: YB202607130008; 失败原因: 监管平台连接超时
          步骤：1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接
            预期：super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页
          备注：对应TP-B-008
        tc-P1-功能测试：验证上传失败状态下运营人员可点击手动上传按钮重新发起上报
          pc：1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130009
          步骤：1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成
            预期：操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin"
          备注：对应TP-B-009
        tc-P0-功能测试：验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交
          pc：1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130010
          步骤：1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮
            预期：前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生）
          备注：[AI修正: 历史缺陷防御] - BUG-202607-02
        tc-P0-功能测试：验证同一运单同一阶段快速连续点击手动上传仅发起1次请求
          pc：1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130011; 快速点击5次
          步骤：1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数
            预期：上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录
          备注：[AI修正: 历史缺陷防御] - BUG-202607-02
        tc-P1-功能测试：验证第一次上报接口超时(>30s)后转为上传失败并触发重试
          pc：1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒
          测试数据：运单号: YB202607130012; 超时阈值: 30s
          步骤：1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理
            预期：前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态
          备注：对应TP-B-015
        tc-P2-功能测试：验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作
          pc：1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报
          测试数据：运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30%
          步骤：1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复
            预期：请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复
          备注：对应TP-B-016
        tc-P2-性能测试：验证10个运单同时装货完成时并发上报互不干扰
          pc：1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货"
          测试数据：10条运单同时装货完成
          步骤：1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态
            预期：10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新
          备注：对应TP-B-017
        tc-P3-功能测试：验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报
          pc：1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称
          测试数据：运单号: YB202607130024; 可选字段全为空
          步骤：1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗
            预期：上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined"
          备注：对应TP-B-018
        tc-P3-功能测试：验证运单包含1条货物记录时正常上报
          pc：1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨"
          测试数据：运单号: YB202607130025; 货物: 钢材 10.5吨
          步骤：1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示
            预期：goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录
          备注：对应TP-B-019
        tc-P3-功能测试：验证运单包含5条货物记录时各货物独立完整上报
          pc：1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方
          测试数据：运单号: YB202607130026; 货物: 5条
          步骤：1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示
            预期：goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确
          备注：对应TP-B-019
        tc-P1-功能测试：验证第一次上报业务类型代码和运输组货方式代码为有效枚举值
          pc：1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运)
          测试数据：运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10
          步骤：1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝
            预期：有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台
          备注：对应TP-B-003
        tc-P2-功能测试：验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态
          pc：1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130028; 异常原因示例: 司机资质核验不通过
          步骤：1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段
            预期：异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空
          备注：对应TP-B-013
        tc-P2-功能测试：验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色
          pc：1. 准备4条运单各处于不同上报状态
          测试数据：运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常
          步骤：1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色
            预期：上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁
          备注：对应TP-B-010
        tc-P1-功能测试：验证第一次上报列表14个字段完整展示且顺序正确
          pc：1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录
          测试数据：运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001
          步骤：1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式
            预期：列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列
          备注：对应TP-B-020；[AI修正: 覆盖缺口补充]
        tc-P0-功能测试：验证未上传委托合同（框架）时第一次上报被拒绝并提示需要先上传委托合同
          pc：1. 系统中存在一条安徽税源地(34)的运单YB202607130092；2. 该运单对应的货主尚未上传委托合同（框架）
          测试数据：运单号: YB202607130092; 委托合同状态: 未上传
          步骤：1. 触发运单装货完成事件；2. 查看第一次上报的返回结果；3. 查看上报日志中的错误信息
            预期：第一次上报接口返回错误，消息明确提示"请先上传委托合同（框架）"或类似文案；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败，错误原因明确；上传委托合同后重试第一次上报可成功
          备注：对应TP-B-021；[技术方案] showdoc文档委托合同前置条件
        tc-P1-功能测试：验证委托合同（框架）支持关联多家托运企业—enterpriseList多企业列表上传
          pc：1. 使用super_admin登录管理端或通过API；2. 准备3家货主企业信息（统一社会信用代码+企业名称）
          测试数据：合同编号: FRAME202607001; enterpriseList: [企业A(9134XXXXXXXXXX01), 企业B(9134XXXXXXXXXX02), 企业C(9134XXXXXXXXXX03)]
          步骤：1. 调用委托合同（框架）上传接口POST /api/dataUpload/mandateContractFrame；2. 传入enterpriseList（含3家企业）、contract_number、expire_time；3. 查看接口返回；4. 再传入unified_social_credit_identifier（单企业）+enterpriseList（多企业）同时传值
            预期：enterpriseList仅传时上报成功，3家企业均关联至该框架合同；同时传unified_social_credit_identifier和enterpriseList时默认取单企业（enterpriseList被忽略）；上传后第一次上报时consignorInfo中frameContractNumber与该框架合同编号一致即可通过
          备注：对应TP-B-022；[技术方案] showdoc文档mandateContractFrame
      平台端-监管上报-第二次上报
        tc-P0-功能测试：验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息
          pc：1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00
          测试数据：运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行
          步骤：1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看
            预期：第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2
          备注：对应TP-C-001
        tc-P0-功能测试：验证第二次上报资金流水数据来源于支付流水表（非运单缓存）
          pc：1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成
          测试数据：运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00
          步骤：1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源
            预期：上报数据中的金额与支付流水表实际打款金额¥10,000.000完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额保留3位小数（如10000.000），无精度丢失
          备注：[AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数
        tc-P0-功能测试：验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额），精度3位小数
          pc：1. 运单YB202607130001合同金额¥10,000.000；2. 财务在账户管理模块调账将打款金额修改为¥9,500.000；3. 财务执行打款
          测试数据：运单号: YB202607130001; 合同金额: ¥10,000.000; 修改后打款金额: ¥9,500.000
          步骤：1. 财务修改打款金额（¥10,000.000→¥9,500.000）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段
            预期：上报请求中的金额为¥9,500.000（修改后的值，3位小数），非¥10,000.000（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额
          备注：[AI修正: 历史缺陷防御] - BUG-202607-03；[技术方案] 第二次上报金额精度3位小数
        tc-P1-功能测试：验证第二次上报列表17个字段完整且收款账号类型标签颜色正确
          pc：1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户）
          测试数据：运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号)
          步骤：1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色
            预期：列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留**3位小数**（如¥10,000.000）；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签
          备注：对应TP-C-004; TP-C-005；[技术方案] 第二次上报金额精度3位小数
        tc-P0-功能测试：验证运单重复核验—首次上报的运单核验通过
          pc：1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报
          测试数据：运单号: YB202607130001(首次上报)
          步骤：1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项
            预期：核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass'
          备注：对应TP-C-006
        tc-P0-功能测试：验证运单重复核验—重复上报检测到异常并标注异常项
          pc：1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报
          测试数据：运单号: YB202607130001(重复上报)
          步骤：1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回
            预期：核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用
          备注：对应TP-C-007
        tc-P1-功能测试：验证车辆资质核验—道路运输证在有效期内核验通过
          pc：1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过"
          测试数据：运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01
          步骤：1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项
            预期：核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass'
          备注：对应TP-C-008
        tc-P1-功能测试：验证车辆资质核验—道路运输证已过期时核验异常
          pc：1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成
          测试数据：运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期)
          步骤：1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情
            预期：核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉
          备注：对应TP-C-009
        tc-P1-功能测试：验证司机资质核验—从业资格证在有效期内核验通过
          pc：1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过"
          测试数据：运单号: YB202607130001; 从业资格证: 有效期内
          步骤：1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态
            预期：核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass
          备注：对应TP-C-010
        tc-P1-功能测试：验证司机资质核验—从业资格证已过期时核验异常
          pc：1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成
          测试数据：运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期)
          步骤：1. 触发第二次上报；2. 等待核验结果；3. 查看异常项
            预期：核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉
          备注：对应TP-C-011
        tc-P1-功能测试：验证集中支付核验—付款方为平台统一账户时核验通过
          pc：1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成
          测试数据：运单号: YB202607130001; 付款方: 网货平台统一账户
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配
          备注：对应TP-C-012
        tc-P1-功能测试：验证集中支付核验—付款方非平台统一账户时核验异常
          pc：1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成
          测试数据：运单号: YB202607130031; 付款方: 第三方代付账户(非平台)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉
          备注：对应TP-C-013
        tc-P1-功能测试：验证资金流水核验—流水号唯一且金额匹配时核验通过
          pc：1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致
          测试数据：运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass
          备注：对应TP-C-014
        tc-P1-功能测试：验证资金流水核验—流水号重复时核验异常
          pc：1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001）
          测试数据：运单号: YB202607130032; 重复流水号: PAY202607130001
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉
          备注：对应TP-C-015
        tc-P1-功能测试：验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常
          pc：1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01）
          测试数据：运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00
          步骤：1. 触发第二次上报（携带错误金额）；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉
          备注：对应TP-C-015
        tc-P1-功能测试：验证合同核验—承运合同和委托合同均有效时核验通过
          pc：1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用）
          测试数据：运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass
          备注：对应TP-C-016
        tc-P1-功能测试：验证合同核验—承运合同不存在时核验异常
          pc：1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统
          测试数据：运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉
          备注：对应TP-C-017
        tc-P1-功能测试：验证合同核验—合同有效期不覆盖运单执行日期时核验异常
          pc：1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期）
          测试数据：运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉
          备注：对应TP-C-017
        tc-P1-功能测试：验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过
          pc：1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配
          测试数据：运单号: YB202607130001; 轨迹点数: 500
          步骤：1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果
            预期：核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass
          备注：对应TP-C-018
        tc-P2-功能测试：验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过
          pc：1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值）
          测试数据：运单号: YB202607130036; 轨迹点数: 2(边界最小值)
          步骤：1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果
            预期：核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理
          备注：对应TP-C-018
        tc-P2-功能测试：验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过
          pc：1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值）
          测试数据：运单号: YB202607130037; 轨迹点数: 2000(边界最大值)
          步骤：1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输
            预期：核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿
          备注：对应TP-C-018
        tc-P1-功能测试：验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常
          pc：1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点
          测试数据：运单号: YB202607130038; 轨迹点数: 1(不足)
          步骤：1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程
          备注：对应TP-C-019
        tc-P1-功能测试：验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常
          pc：1. 运单YB202607130039无GPS轨迹数据（轨迹点=0）
          测试数据：运单号: YB202607130039; 轨迹点数: 0
          步骤：1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程
          备注：对应TP-C-019
        tc-P0-功能测试：验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝
          pc：1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作
          测试数据：运单号: YB202607130005(第一次上报失败)
          步骤：1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表
            预期：第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P0-功能测试：验证第二次上报幂等性—自动重试期间禁止手动触发
          pc：1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130001(自动重试进行中)
          步骤：1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API
            预期：前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入
          备注：[AI修正: 历史缺陷防御] - BUG-202607-02
        tc-P1-功能测试：验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过
          pc：1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点）
          测试数据：运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200
          步骤：1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果
            预期：仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据
          备注：对应TP-C-022
        tc-P1-功能测试：验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警
          pc：1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时）
          测试数据：运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值)
          步骤：1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知
            预期：上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中"
          备注：[AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023
        tc-P2-功能测试：验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示
          pc：1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据
          测试数据：运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位
          步骤：1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段
            预期：资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息
          备注：对应TP-C-024；[AI修正: 覆盖缺口补充]
        tc-P1-功能测试：验证里程申诉功能—提交里程申诉接口正常
          pc：1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%）
          测试数据：运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001
          步骤：1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交
            预期：里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰
          备注：对应TP-C-025；[技术方案] API新增接口
        tc-P1-功能测试：验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过
          pc：1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成
          测试数据：运单号: YB202607130059; 委托合同: DLC202607001(有效)
          步骤：1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项
            预期：核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录
          备注：对应TP-C-026；[技术方案] API文档§4.1
        tc-P1-功能测试：验证委托合同核验(100)—合同不存在或过期时核验异常
          pc：1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成
          测试数据：运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在)
          步骤：1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情
            预期：核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉
          备注：对应TP-C-027；[技术方案] API文档§4.1
        tc-P1-功能测试：验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过
          pc：1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成
          测试数据：运单号: YB202607130061; 承运合同: CTC202607001(有效)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录
          备注：对应TP-C-028；[技术方案] API文档§4.1
        tc-P1-功能测试：验证承运合同核验(120)—合同不存在或过期时核验异常
          pc：1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成
          测试数据：运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉
          备注：对应TP-C-029；[技术方案] API文档§4.1
        tc-P1-功能测试：验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过
          pc：1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成
          测试数据：运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"实时定位核验"（代码130）异常项
          备注：对应TP-C-030；[技术方案] API文档§4.1
        tc-P1-功能测试：验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常
          pc：1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成
          测试数据：运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据
          备注：对应TP-C-031；[技术方案] API文档§4.1
        tc-P1-功能测试：验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过
          pc：1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成
          测试数据：运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项
          备注：对应TP-C-032；[技术方案] API文档§4.1
        tc-P1-功能测试：验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常
          pc：1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成
          测试数据：运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉
          备注：对应TP-C-033；[技术方案] API文档§4.1
        tc-P1-功能测试：验证道路运输证核验(160)—有效期和证号均有效时核验通过
          pc：1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成
          测试数据：运单号: YB202607130067; 道路运输证号: RTC202501001(有效)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"道路运输证核验"（代码160）异常项
          备注：对应TP-C-034；[技术方案] API文档§4.1
        tc-P1-功能测试：验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常
          pc：1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成
          测试数据：运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉
          备注：对应TP-C-035；[技术方案] API文档§4.1
        tc-P1-功能测试：验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过
          pc：1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成
          测试数据：运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"驾驶证核验"（代码170）异常项
          备注：对应TP-C-036；[技术方案] API文档§4.1
        tc-P1-功能测试：验证驾驶证核验(170)—驾驶证已过期时核验异常
          pc：1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成
          测试数据：运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉
          备注：对应TP-C-037；[技术方案] API文档§4.1
        tc-P1-功能测试：验证车辆重复核验(190)—车辆无时间重叠运单时核验通过
          pc：1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成
          测试数据：运单号: YB202607130071; 车辆: 云A12345(无时间重叠)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"车辆重复核验"（代码190）异常项
          备注：对应TP-C-038；[技术方案] API文档§4.1
        tc-P1-功能测试：验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常
          pc：1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成
          测试数据：运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13
          步骤：1. 分别触发两个运单的第二次上报；2. 查看核验结果
            预期：至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉
          备注：对应TP-C-039；[技术方案] API文档§4.1
        tc-P1-功能测试：验证司机重复核验(200)—司机无时间重叠运单时核验通过
          pc：1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成
          测试数据：运单号: YB202607130074; 司机: 张三(无时间重叠)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"司机重复核验"（代码200）异常项
          备注：对应TP-C-040；[技术方案] API文档§4.1
        tc-P1-功能测试：验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常
          pc：1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成
          测试数据：运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠)
          步骤：1. 分别触发两个运单的第二次上报；2. 查看核验结果
            预期：至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉
          备注：对应TP-C-041；[技术方案] API文档§4.1
        tc-P1-功能测试：验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过
          pc：1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成
          测试数据：运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"运费收款核验"（代码220）异常项
          备注：对应TP-C-042；[技术方案] API文档§4.1
        tc-P1-功能测试：验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常
          pc：1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成
          测试数据：运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉
          备注：对应TP-C-043；[技术方案] API文档§4.1
        tc-P1-功能测试：验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过
          pc：1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成
          测试数据：运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态为"通过"；无"公司统一收款核验"（代码230）异常项
          备注：对应TP-C-044；[技术方案] API文档§4.1
        tc-P1-功能测试：验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常
          pc：1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成
          测试数据：运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致)
          步骤：1. 触发第二次上报；2. 等待核验结果
            预期：核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉
          备注：对应TP-C-045；[技术方案] API文档§4.1
        tc-P1-功能测试：验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过
          pc：1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成
          测试数据：运单号: YB202607130081; 发票号: FP202607130081(有效)
          步骤：1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果
            预期：核验状态为"通过"；无"发票信息核验"（代码260）异常项
          备注：对应TP-C-046；[技术方案] API文档§4.1
        tc-P1-功能测试：验证发票信息核验(260)—发票已作废时核验异常
          pc：1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成
          测试数据：运单号: YB202607130082; 发票号: FP202607130082(已作废)
          步骤：1. 触发第三次上报后等待发票核验；2. 查看核验结果
            预期：核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉
          备注：对应TP-C-047；[技术方案] API文档§4.1
        tc-P1-功能测试：验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过
          pc：1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成
          测试数据：运单号: YB202607130083; 车辆证照: 齐全有效
          步骤：1. 触发上报后等待核验；2. 查看核验结果
            预期：核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项
          备注：对应TP-C-048；[技术方案] API文档§4.1
        tc-P1-功能测试：验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常
          pc：1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成
          测试数据：运单号: YB202607130084; 车辆状态: 黑名单
          步骤：1. 触发上报后等待核验；2. 查看核验结果
            预期：核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉
          备注：对应TP-C-049；[技术方案] API文档§4.1
        tc-P2-功能测试：验证第二次上报核验详情中每个异常项有独立申诉入口
          pc：1. 运单YB202607130091第二次上报存在两个核验异常项：车辆轨迹(210)和资金流水(250)；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130091; 异常项: 车辆轨迹(210), 资金流水(250)
          步骤：1. 进入第二次上报列表，点击该运单的"详情"按钮；2. 查看核验详情弹窗中的异常项列表；3. 验证每个异常项旁是否有独立的"申诉"操作按钮
            预期：核验详情弹窗中每个异常项均有独立的"申诉"按钮或操作入口；点击异常项210的"申诉"按钮后跳转至申诉页面，且verificationAbnormalItems预填充为"210"；点击异常项250的"申诉"按钮后预填充"250"；两个申诉入口独立触发，互不影响
          备注：对应TP-C-024；[AI修正: 申诉单值约束意识]
        tc-P1-功能测试：验证第二次上报所有金额字段保留3位小数—整数填.000、精度无丢失
          pc：1. 准备运单YB202607130093含各种金额场景：整数100、小数100.5、小数100.123；2. 第一次上报已完成，财务打款完成
          测试数据：运单号: YB202607130093; 承运运费: 100(整数)/100.5(1位小数)/100.123(3位小数); 委托运费: 150.5; 承运人流水金额: 10000; 货主流水金额: 10500.25; 承运合同金额: 12000.5; 委托合同金额: 11000.125
          步骤：1. 触发第二次上报；2. 查看上报请求JSON中各金额字段的值；3. 验证数据库存储和UI展示的精度
            预期：waybillFreightAmount整数100→"100.000"；totalMonetaryAmount小数150.5→"150.500"；carrierStatements[0].monetaryAmount整数10000→"10000.000"；ownerStatements[0].monetaryAmount小数10500.25→"10500.250"；carrierContractInfo.contractAmount小数12000.5→"12000.500"；carrierContractInfo.contractedCarryingCapacity→3位小数；ownerContractInfo相同规则；数据库所有金额字段使用DECIMAL(18,3)类型非FLOAT；UI展示也同步为3位小数格式
          备注：对应TP-C-050；[技术方案] showdoc文档第二次上报金额精度3位小数
      平台端-监管上报-第三次上报
        tc-P0-功能测试：验证发票开具完成后自动触发第三次上报且包含发票信息17字段
          pc：1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成
          测试数据：运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00
          步骤：1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看
            预期：第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录
          备注：对应TP-D-001
        tc-P1-功能测试：验证第三次上报列表展示13个字段完整且数据正确
          pc：1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录
          测试数据：运单号: YB202607130001; 发票号: FP202607130001
          步骤：1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容
            预期：列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范
          备注：对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列
        tc-P1-功能测试：验证第三次上报详情弹窗发票信息19字段完整展示
          pc：1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成
          测试数据：运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00
          步骤：1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段
            预期：发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段
          备注：对应TP-D-003
        tc-P2-功能测试：验证运单关联油气发票时第三次上报包含油气发票信息
          pc：1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成
          测试数据：运单号: YB202607130040; 油气发票: YQFP202607001
          步骤：1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗
            预期：上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载
          备注：对应TP-D-004
        tc-P2-功能测试：验证无油气发票时第三次上报正常完成（可选字段为空）
          pc：1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成
          测试数据：运单号: YB202607130001; 油气发票: 无
          步骤：1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段
            预期：上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无"
          备注：对应TP-D-004
        tc-P0-功能测试：验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝
          pc：1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成
          测试数据：运单号: YB202607130041(第二次上报失败)
          步骤：1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回
            预期：接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P0-功能测试：验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝
          pc：1. 运单YB202607130042第一次上报状态为"上传失败"
          测试数据：运单号: YB202607130042
          步骤：1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回
            预期：第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P1-功能测试：验证增值税发票号码格式无效时第三次上报失败并明确提示
          pc：1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成
          测试数据：运单号: YB202607130043; 发票号码: ABC(无效格式)
          步骤：1. 触发第三次上报；2. 查看上报接口返回的错误信息
            预期：接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录
          备注：对应TP-D-006
        tc-P1-功能测试：验证发票代码与发票号码不匹配时第三次上报失败
          pc：1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配
          测试数据：运单号: YB202607130044; 不匹配的发票代码/号码
          步骤：1. 触发第三次上报；2. 查看接口返回
            预期：接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段
          备注：对应TP-D-006
        tc-P1-功能测试：验证第三次上报失败后自动重试最多3次全部失败后告警
          pc：1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败
          测试数据：运单号: YB202607130045; 发票号: FP202607130045
          步骤：1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知
            预期：自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因
          备注：对应TP-D-007
        tc-P1-功能测试：验证第三次上报幂等性—同一运单同一发票信息不能重复上报
          pc：1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报
          测试数据：运单号: YB202607130001; 发票号: FP202607130001(已上报)
          步骤：1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回
            预期：接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发
          备注：对应TP-D-009
        tc-P1-功能测试：验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题
          pc：1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票
          测试数据：金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99
          步骤：1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额
            预期：三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致
          备注：对应TP-D-010
        tc-P2-功能测试：验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据
          pc：1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨"
          测试数据：运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨
          步骤：1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据
            预期：上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存
          备注：对应TP-D-011
        tc-P2-功能测试：验证第三次上报详情弹窗异常信息分组与申诉模块数据联动
          pc：1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中"
          测试数据：运单号: YB202607130046; 申诉状态: 申诉中
          步骤：1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组
            预期：异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新
          备注：对应TP-D-008
        tc-P1-功能测试：验证发票合规查询接口—查询托运人发票是否通过系统核验合规
          pc：1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录
          测试数据：托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX
          步骤：1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态
            预期：接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示
          备注：对应TP-D-012；[技术方案] API新增接口
      平台端-监管上报-ETC上传
        tc-P0-功能测试：验证运营人员手动确认税务抵扣完成后触发ETC发票上传并成功
          pc：1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成（税务系统侧）；2. ETC发票信息18字段完整
          测试数据：运单号: YB202607130001; ETC发票号: ETC202607130001; 不含税金额(invoiceAmount): ¥100.00; 税率: 3%
          步骤：1. 运营人员在运八系统手动确认"抵扣完成"；2. 系统收到确认后触发ETC发票上传；3. 进入管理端"监管上报-ETC上传"列表查看；4. 查看上传请求JSON内容
            预期：运营人员确认后系统自动触发上传；ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1
          备注：对应TP-E-001；[技术方案] 触发方式修正：运营人员手动确认→系统触发
        tc-P1-功能测试：验证ETC上传列表展示11个字段完整且数据正确
          pc：1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录
          测试数据：运单号: YB202607130001; ETC发票号: ETC202607130001
          步骤：1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列
            预期：列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范
          备注：对应TP-E-002
        tc-P2-功能测试：验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息）
          pc：1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录
          测试数据：运单号: YB202607130001; ETC发票号: ETC202607130001
          步骤：1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段
            预期：运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态）
          备注：对应TP-E-003
        tc-P0-功能测试：验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣"
          pc：1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成"
          测试数据：运单号: YB202607130047; 税务抵扣: 未完成
          步骤：1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回
            预期：上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录
          备注：对应TP-E-004
        tc-P1-功能测试：验证ETC发票号码格式无效时上传失败并明确提示
          pc：1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式）
          测试数据：运单号: YB202607130048; ETC发票号码: ETC-ABC(无效)
          步骤：1. 税务抵扣完成后触发上传；2. 查看接口返回
            预期：上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段
          备注：对应TP-E-005
        tc-P1-功能测试：验证ETC发票税率非3%时上传失败并提示税率异常
          pc：1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%）
          测试数据：运单号: YB202607130049; ETC发票税率: 5%(非标准)
          步骤：1. 触发上传；2. 查看接口返回
            预期：上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台
          备注：对应TP-E-005
        tc-P1-功能测试：验证ETC上传失败后自动重试最多3次全部失败后告警
          pc：1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败
          测试数据：运单号: YB202607130050; ETC发票号: ETC202607130050
          步骤：1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警
            预期：自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志
          备注：对应TP-E-006
        tc-P1-功能测试：验证ETC税额计算公式—税额=不含税金额×税率(taxRate)，字段区分invoiceAmount/totalPriceAndTax
          pc：1. 准备3张ETC发票：不含税金额(invoiceAmount)分别为¥100.00、¥0.01、¥1,000,000.00，税率3%
          测试数据：发票1: invoiceAmount=100.00→税额=3.00; 发票2: invoiceAmount=0.01→税额=0.00; 发票3: invoiceAmount=1000000.00→税额=30000.00
          步骤：1. 分别对三张发票触发上传；2. 查看上报请求JSON中的invoiceAmount(不含税金额)、taxRate(税率)、taxAmount(税额)、totalPriceAndTax(价税合计)字段；3. 验证计算逻辑: totalPriceAndTax = invoiceAmount + taxAmount
            预期：发票1: invoiceAmount=100.00, taxAmount=3.00, totalPriceAndTax=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: invoiceAmount=1000000.00, taxAmount=30000.00, totalPriceAndTax=1030000.00, 大金额计算不溢出；所有金额字段保留2位小数；invoiceAmount≠发票总金额，是不含税金额
          备注：对应TP-E-007；[技术方案] 字段语义修正：invoiceAmount=不含税金额（非总金额）
        tc-P1-功能测试：验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传"
          pc：1. ETC发票ETC202607130001已成功上传
          测试数据：ETC发票号: ETC202607130001(已上传)
          步骤：1. 再次触发同一ETC发票的上传；2. 查看接口返回
            预期：接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发
          备注：对应TP-E-008
        tc-P2-功能测试：验证同一运单关联多张ETC发票时各自独立上传且税额分别计算
          pc：1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00)
          测试数据：ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50
          步骤：1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算
            预期：列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总
          备注：对应TP-E-009
        tc-P1-功能测试：验证ETC发票代码与号码不匹配时上传失败
          pc：1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票）
          测试数据：运单号: YB202607130051; 不匹配的ETC发票代码/号码
          步骤：1. 触发上传；2. 查看接口返回
            预期：上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段
          备注：对应TP-E-005
        tc-P1-功能测试：验证交易金额与实际通行费不匹配时ETC上传验证失败
          pc：1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配
          测试数据：运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配)
          步骤：1. 触发上传；2. 查看接口返回
            预期：上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败"
          备注：对应TP-E-005
      平台端-监管上报-异常申诉
        tc-P0-功能测试：验证申诉完整闭环—从发起申诉到申诉通过的端到端流程
          pc：1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF）
          测试数据：运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf
          步骤：1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化
            预期：提交申诉后申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110，省平台尚未审核）；省平台复核通过后状态变为"审核通过(110)"（绿色标签，终态）；申诉记录页面中该申诉记录状态为"审核通过(110)"；处理记录时间线中每条操作均有记录；申诉状态中"已取消(130)"为省平台侧外部操作设置（如运单作废），我方系统只读同步，不提供取消操作入口
          备注：对应TP-F-001；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)由省平台侧操作，我方只读
        tc-P1-功能测试：验证申诉审核不通过(120)后运营人员重新申诉补充材料再发起
          pc：1. 运单YB202607130002申诉状态为"审核不通过(120)"；2. 省平台反馈意见"证明材料不充分"
          测试数据：运单号: YB202607130002; 原申诉被审核不通过; 新附件: 补充证明.pdf
          步骤：1. 进入申诉记录页面，找到审核不通过的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交
            预期："重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失（状态保持审核不通过120）；新申诉有独立的处理记录时间线；申诉状态变为"未申诉(100)·申诉中"（abnormalDetails[].state=110），重新进入复核流程
          备注：对应TP-F-006
        tc-P1-功能测试：验证申诉记录列表14个字段完整展示
          pc：1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录
          测试数据：申诉单含完整字段
          步骤：1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列
            预期：列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致
          备注：对应TP-F-002
        tc-P0-功能测试：验证申诉状态流转—未申诉(100)→未申诉·申诉中→审核通过(110)(终态)或审核不通过(120)(可重申诉)
          pc：1. 运单YB202607130053核验异常且申诉状态为"未申诉(100)"
          测试数据：运单号: YB202607130053
          步骤：1. 发起申诉，验证异常项子状态变为"申诉中"(abnormalDetails[].state=110)；2. 模拟省平台复核通过；3. 验证申诉状态变为"审核通过(110)"；4. 尝试再次对该申诉记录操作（如重新申诉）；5. 模拟省平台审核不通过→验证状态变为"审核不通过(120)"→可重新申诉
            预期：未申诉(100)→提交申诉后异常项子状态变为申诉中(state=110)，申诉状态仍为未申诉(100)；省平台审核通过后申诉状态变为审核通过(110)（终态，不可再变更）；省平台审核不通过变为审核不通过(120)，可重新申诉发起新一轮；已取消(130)由省平台外部操作设置（如运单作废），我方UI不提供取消申诉入口，仅展示同步后的状态；每次状态变更记录到处理记录时间线
          备注：对应TP-F-003；[API权威] 申诉状态以API §4.4为准: 未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)；已取消(130)为省平台侧外部操作，我方只读
        tc-P0-功能测试：验证申诉状态流转—未申诉·申诉中状态下不可重复发起申诉
          pc：1. 运单YB202607130054申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110）
          测试数据：运单号: YB202607130054; 申诉状态: 未申诉·申诉中
          步骤：1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应
            预期：页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录
          备注：对应TP-F-003; TP-F-012
        tc-P2-功能测试：验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录）
          pc：1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录
          测试数据：申诉单号: APL202607130001
          步骤：1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容
            预期：申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录
          备注：对应TP-F-004
        tc-P2-功能测试：验证申诉附件上传—支持多附件且格式校验正确
          pc：1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB)
          测试数据：附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB)
          步骤：1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件
            预期：png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件
          备注：对应TP-F-005
        tc-P1-功能测试：验证17项核验异常（API文档§4.1定义）各自独立发起申诉—每次仅可申诉单个异常项
          pc：1. 准备17条运单（或组合覆盖），每条分别对应一种核验异常项；2. 使用super_admin登录管理端
          测试数据：运单A: 委托合同(100); B: 承运合同(120); C: 实时定位(130); D: 运单时间逻辑(140); E: 车辆资质(150); F: 道路运输证(160); G: 驾驶证(170); H: 从业资格证(180); I: 车辆重复(190); J: 司机重复(200); K: 车辆轨迹(210); L: 运费收款(220); M: 公司统一收款(230); N: 集中支付(240); O: 资金流水(250); P: 发票信息(260); Q: 非通行车辆可开票(270)
          步骤：1. 分别对17种异常项运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰；4. 确认每次申诉仅含单个verificationAbnormalItems值
            预期：17条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的verificationAbnormalItems字段为单一异常项ID；某一异常项申诉不影响其他异常项的申诉状态；同一运单存在多个异常项时需分别独立发起申诉（参见AH_REPORT_APL_019）
          备注：对应TP-F-007；[API权威] API文档§4.1定义17项核验，每项均可独立申诉但每次只允许申诉单个异常项（单值约束）
        tc-P1-功能测试：验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号
          pc：1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130002
          步骤：1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据
            预期：页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号
          备注：对应TP-F-008
        tc-P1-安全性测试：验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限
          pc：1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号
          测试数据：运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888
          步骤：1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口
            预期：运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因）
          备注：对应TP-F-009
        tc-P2-功能测试：验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒
          pc：1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录
          测试数据：申诉单号: APL202607130002
          步骤：1. 进入申诉详情弹窗；2. 查看"处理记录"时间线
            预期：4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应
          备注：对应TP-F-010
        tc-P2-功能测试：验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称
          pc：1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"）
          测试数据：异常代码: VEHICLE_QUAL_FAIL
          步骤：1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确
            预期：申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义
          备注：对应TP-F-011
        tc-P2-功能测试：验证未知异常代码兜底展示—显示原始代码+标注未知异常
          pc：1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"）
          测试数据：未知异常代码: UNKNOWN_ERROR_999
          步骤：1. 查看申诉页面异常项的展示
            预期：申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查
          备注：对应TP-F-011
        tc-P2-功能测试：验证同一异常项未申诉·申诉中状态下快速双击提交申诉仅产生1条记录
          pc：1. 运单YB202607130055核验异常，申诉状态为"未申诉(100)"，异常项子状态为"未申诉"(state=100)
          测试数据：运单号: YB202607130055; 异常项: 资金流水核验
          步骤：1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表
            预期：申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"未申诉·申诉中"(abnormalDetails[].state=110)状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"未申诉·申诉中"记录
          备注：对应TP-F-012
        tc-P3-功能测试：验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示
          pc：1. 运单YB202607130056申诉状态为"未申诉(100)·申诉中"（abnormalDetails[].state=110），省平台尚未审核；2. 模拟时间超过7个工作日省平台无反馈
          测试数据：运单号: YB202607130056; 等待时长: 超过7个工作日
          步骤：1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警
            预期：申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"未申诉(100)·申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为审核通过(110)或审核不通过(120)；已取消(130)由省平台侧外部操作（如运单作废），我方只读同步，不主动发起取消
          备注：对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认
        tc-P2-功能测试：验证申诉附件上传失败时有重试机制
          pc：1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用
          测试数据：附件: 证明文件.png(500KB)
          步骤：1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常
            预期：附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容
          备注：对应TP-F-005
        tc-P1-安全性测试：验证财务人员可查看申诉记录但不可发起申诉
          pc：1. 使用财务账号登录管理端；2. 申诉记录中有数据
          测试数据：财务账号: finance_user
          步骤：1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口
            预期：申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作
          备注：对应TP-F-009
        tc-P0-功能测试：验证申诉表单仅允许选择单个异常项—verificationAbnormalItems单值约束
          pc：1. 运单YB202607130090同时存在两个异常项：车辆轨迹210和资金流水250；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130090; 异常项: 210(车辆轨迹), 250(资金流水)
          步骤：1. 进入申诉页面；2. 查看异常项选择区域；3. 尝试选择一个异常项后提交；4. 尝试多选异常项
            预期：UI层面异常项为单选列表（Radio Button或单选下拉），无法多选；提交请求中verificationAbnormalItems字段为单值（如"210"），非逗号分隔多值；若通过API绕过前端传入逗号分隔多值"210,250"，后端返回错误（如code=500，message包含"仅支持单个异常项目申诉"）
          备注：对应TP-F-014；[技术方案] API单值约束
        tc-P1-功能测试：验证同一运单两个异常项需分别发起两次独立申诉
          pc：1. 运单YB202607130090有两个异常项210+250，均状态为"未申诉"；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130090; 申诉1: 异常项210; 申诉2: 异常项250
          步骤：1. 对异常项210(车辆轨迹)发起申诉→填写申诉内容→上传附件→提交；2. 验证申诉提交成功；3. 返回申诉页面，再次对异常项250(资金流水)发起申诉→填写内容→提交
            预期：两次申诉生成两个独立申诉单号（complaintNumber不同）；数据库appeal_record表存在两条记录，分别对应异常项210和异常项250；两个异常项的申诉状态独立流转，互不影响；第二次申诉的异常项选择区域仅展示尚未申诉的异常项（250），已申诉的异常项210不再可选
          备注：对应TP-F-015；[技术方案] 独立申诉单
        tc-P1-安全性测试：验证申诉接口传入逗号分隔多异常项ID时后端拒绝
          pc：1. 运单YB202607130090有两个异常项210和250均未申诉；2. 获取有效JWT Token
          测试数据：运单号: YB202607130090; verificationAbnormalItems: "210,250"(逗号分隔,非法)
          步骤：1. 通过API直接调用POST /appeal/insert接口；2. verificationAbnormalItems参数传入"210,250"（逗号分隔）；3. 查看接口返回
            预期：接口返回错误（code=500），message包含"仅支持单个异常项目申诉"或"verificationAbnormalItems必须为单一异常项ID"；数据库appeal_record表不产生新记录；不会错误地创建关联多个异常项的申诉单；单独传入"210"或"250"（单值）时正常成功
          备注：对应TP-F-016；[技术方案] 后端校验多值拒绝
      平台端-监管上报-上报日志
        tc-P0-功能测试：验证上报日志按完整运单号精确搜索日志记录
          pc：1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录
          测试数据：运单号: YB202607130001
          步骤：1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索
            预期：列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致
          备注：对应TP-G-001
        tc-P1-功能测试：验证上报日志按不存在的单号搜索显示空结果
          pc：1. 使用super_admin登录管理端
          测试数据：运单号: NOTEXIST999
          步骤：1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索
            预期：列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错
          备注：对应TP-G-001
        tc-P0-功能测试：验证上报日志按"第一次上报"阶段筛选日志
          pc：1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录
          测试数据：筛选条件: 第一次上报
          步骤：1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果
            预期：列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤
          备注：对应TP-G-002
        tc-P1-功能测试：验证上报日志按"失败"结果筛选—展示所有非成功日志
          pc：1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录
          测试数据：筛选: 失败
          步骤：1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果
            预期：列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致
          备注：对应TP-G-003
        tc-P1-功能测试：验证上报日志按时间范围筛选（跨天）
          pc：1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录
          测试数据：时间范围: 2026-07-10~2026-07-12
          步骤：1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索
            预期：列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部
          备注：对应TP-G-004
        tc-P1-功能测试：验证上报日志列表11个字段完整展示
          pc：1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录
          测试数据：查看一条典型日志记录
          步骤：1. 进入日志页面；2. 查看列表表头和第一条数据的所有列
            预期：列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间
          备注：对应TP-G-005
        tc-P1-功能测试：验证点击日志操作列详情按钮弹窗展示完整请求和响应报文
          pc：1. 使用super_admin登录管理端；2. 日志中有1条失败记录
          测试数据：查看一条HTTP 400失败的日志详情
          步骤：1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文
            预期：弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容
          备注：对应TP-G-006
        tc-P1-功能测试：验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录
          pc：1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC）
          测试数据：运单号: YB202607130001
          步骤：1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段
            预期：日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志）
          备注：对应TP-G-007
        tc-P1-功能测试：验证上报失败日志包含完整的Error Response Body和重试次数标记
          pc：1. 使用super_admin登录管理端；2. 存在上报失败的日志记录
          测试数据：查看一条第2次重试失败的日志
          步骤：1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度
            预期：失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查
          备注：对应TP-G-008
        tc-P2-功能测试：验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人
          pc：1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志
          测试数据：自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传)
          步骤：1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段
            预期：自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致
          备注：对应TP-G-009
        tc-P2-功能测试：验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选
          pc：1. 使用super_admin登录管理端；2. 日志数据满足组合条件
          测试数据：组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713
          步骤：1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索
            预期：列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示
          备注：对应TP-G-001; TP-G-002; TP-G-003; TP-G-004
      平台端-监管上报-跨模块
        tc-P0-功能测试：验证完整三阶段依赖链端到端验证—后端三重前置状态校验
          pc：1. 准备一条安徽税源地(34)的运单YB202607130001
          测试数据：运单号: YB202607130001
          步骤：1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回
            预期：第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储
          备注：[AI修正: 历史缺陷防御] - BUG-202607-01
        tc-P0-功能测试：验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值
          pc：1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00
          测试数据：运单号: YB202607130046; 修改项: 司机/金额/发票
          步骤：1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00
            预期：第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致
          备注：[AI修正: 历史缺陷防御] - BUG-202607-03
        tc-P0-冒烟测试：验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试）
          pc：1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常
          测试数据：运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001
          步骤：1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传"
            预期：第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1
          备注：对应TP-X-003
        tc-P0-功能测试：验证非安徽税源地运单(云南=28)全部阶段均不触发上报
          pc：1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程
          测试数据：运单号: YB202607130002; 省份代码: 28(云南)
          步骤：1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单
            预期：全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转
          备注：对应TP-X-004
        tc-P1-功能测试：验证多省份部署下安徽(34)和云南(28)上报数据完全隔离
          pc：1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条
          测试数据：安徽: YB202607130001(34); 云南: YB202607130002(28)
          步骤：1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台
            预期：安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆
          备注：对应TP-X-005
        tc-P1-功能测试：验证定时任务重试与手动触发上报的并发控制—分布式锁机制
          pc：1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传"
          测试数据：运单号: YB202607130057
          步骤：1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为
            预期：同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行
          备注：对应TP-B-014; TP-C-021
        tc-P2-功能测试：验证回单签收后财务打款前不触发第二次上报—打款完成才触发
          pc：1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款
          测试数据：运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00
          步骤：1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点
            预期：回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间
          备注：对应TP-X-006
        tc-P1-功能测试：验证已上报至服务平台的运单不可取消或删除—无操作入口且API拒绝
          pc：1. 运单YB202607130094已成功完成第一次上报（数据已上传至服务平台）；2. 使用super_admin登录管理端
          测试数据：运单号: YB202607130094; 上报阶段: 第一次上报已完成
          步骤：1. 在管理端查看该运单的操作列，确认是否存在"取消"或"删除"按钮；2. 通过API尝试调用删除/取消运单接口（如DELETE /api/waybill/{id}）；3. 查看接口返回和数据库状态
            预期：UI操作列无"取消"或"删除"按钮（仅显示详情/进度/申诉等）；API层面调用删除接口返回错误（如404或method not allowed），提示"已上报运单不允许取消"；数据库report_record表和运单表数据未被删除或修改；未完结的运单在合规率统计中被排除不计
          备注：对应TP-X-007；[技术方案] showdoc FAQ：服务平台不支持取消或删除运单