feat: 安徽运八需求全流水线输出同步 + 知识库/agents/资源文件更新

output/versions/安徽运八需求/v3/normalized_inputs/requirement.md

@@ -0,0 +1,164 @@
+# 安徽运八需求
+
+> 文档角色：需求文档
+> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx`
+
+安徽运八需求
+一、需求概述
+根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。
+二、功能说明
+2.1 上报运单看板
+· 功能描述
+上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。
+· 查询条件
+运单号/托运单号/货源单号：模糊搜索
+上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报
+核验状态：全部 / 异常 / 通过
+申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回
+操作按钮：查询、重置、导出
+· 列表字段
+货源单号、运单号、托运单号、车牌号、司机姓名、
+托运方名称、上报阶段、核验状态、申诉状态、异常项、
+货物名称、合同金额、最新核验时间、操作（申诉/进度/详情）
+2.2 第一次上报（装货完成）
+功能描述
+第一次上报在运单装货完成后自动触发（仅上传货源税源地为安徽运八的运单，其他税源地无需上传），上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。
+特殊说明
+• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。
+• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。
+• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。
+上报状态规则
+| 状态 | 说明 | 操作按钮 | 标签颜色 |
+| 上传中 | 数据正在上报中 | 无 | 蓝色 |
+| 已上传 | 上报成功 | 无 | 绿色 |
+| 上传失败 | 上报超时 | 手动上传 | 红色 |
+| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 |
+列表字段
+货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情）
+详情弹窗字段分组
+详情弹窗按以下子对象分组展示：
+建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选）
+托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码
+收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度
+司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码
+接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选）
+货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位
+保险信息（可选，2字段）：保险单号、保险公司名称
+异常信息：核验状态、异常原因、异常时间、处理状态
+2.3 第二次上报（打款完成）
+功能描述
+第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。
+特殊说明
+• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。
+• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。
+• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。
+• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
+列表字段
+货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情）
+收款账号类型说明
+• 个人账户：司机个人银行卡账号，标签为蓝色
+• 对公账户：企业银行账号，标签为绿色
+详情弹窗字段分组
+（1）运单信息（必选）：同第一次上报
+（2）托运方信息（必选）：同第一次上报
+（3）收货方信息（必选）：同第一次上报
+（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态
+（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型
+（6）异常信息：核验状态、异常原因、异常时间、处理状态
+核验内容（监管平台自动核验，异常时可发起申诉）
+| 核验项 | 说明 |
+| 运单重复核验 | 检查同一运单是否重复上报 |
+| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 |
+| 司机资质核验 | 检查司机从业资格证是否在有效期内 |
+| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 |
+| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 |
+| 合同核验 | 检查运输合同和委托合同是否有效 |
+| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 |
+2.4 第三次上报（开票完成）
+功能描述
+第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。
+特殊说明
+• 第三次上传需要在运单完成第二次上传后方可进行。
+• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。
+• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
+列表字段
+货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情）
+详情弹窗字段分组
+（1）运单信息（必选）：同第一次上报
+（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号
+（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件
+（4）异常信息：核验状态、异常原因、异常时间、处理状态
+2.5 ETC发票上传
+功能描述
+ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。
+特殊说明
+• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。
+• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。
+• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
+列表字段
+货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情）
+详情弹窗字段分组
+（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称
+（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件
+（3）异常信息：核验状态、异常原因、异常时间、处理状态
+2.6 异常申诉功能
+运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。
+本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。
+当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。
+列表字段
+运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉）
+详情弹窗字段分组
+（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件
+（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称
+（3）异常信息：核验状态、异常原因、异常时间
+（4）省平台反馈信息：反馈结果、反馈时间、反馈意见
+（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示）
+申诉复核说明
+（注：申诉由安徽监管平台复核，非我方审核）
+（复核不通过时，可补充材料后重新发起申诉）
+异常代码一览表
+2.7 上报日志
+功能描述
+上报日志记录所有上报接口的调用记录，用于问题排查和审计。
+查询条件
+• 运单号/托运单号/货源单号：模糊搜索
+• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传
+• 上报结果：全部 / 成功 / 失败
+• 开始时间 ~ 结束时间：时间范围筛选
+列表字段
+序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文）
+三. 数据字段说明
+3.1 第一次上报字段（装货完成）
+核心子对象及必选字段：
+• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage
+• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode
+• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude
+• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode
+• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo
+• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit
+• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany
+3.2 第二次上报字段（打款完成）
+新增字段说明：
+• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient)
+• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount)
+• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列
+3.3 第三次上报字段（开票完成）
+核心字段：
+• 发票号码（invoiceNo）：增值税发票号码
+• 发票代码（invoiceCode）：增值税发票代码
+• 发票金额（invoiceAmount）：价税合计（保留2位小数）
+（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中）
+• 销售方名称（sellerName）：开票方企业名称
+• 受票方名称（buyerName）：托运人/货主企业名称
+3.4 ETC发票字段
+核心字段：
+• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码
+• 入口收费站（entryStation）：通行入口
+• 出口收费站（exitStation）：通行出口
+• 税额（taxAmount）：可抵扣税额（税率3%）
+详细数据接口字段请查阅上报接口：
+https://www.showdoc.com.cn/2210641821476236/9919735893682511
+密码：szjj@2023
+原型文件路径：
+"E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html"
+接口文档路径："E:\Downloads\网货企业端接口文档（最新）.pdf"

output/versions/安徽运八需求/v3/snapshot_meta.json

@@ -0,0 +1,14 @@
+{
+  "base_name": "安徽运八需求",
+  "version": "v3",
+  "snapshot_type": "full_pipeline",
+  "summary": [
+    "manifest",
+    "analysis",
+    "relation_report",
+    "test_points",
+    "test_cases_markdown",
+    "excel",
+    "normalized_inputs"
+  ]
+}

output/versions/安徽运八需求/v3/安徽运八需求.json

@@ -0,0 +1,348 @@
+{
+  "_meta": {
+    "base_name": "安徽运八需求",
+    "merged_zones": [
+      "prepare",
+      "analyze",
+      "design",
+      "execute",
+      "review",
+      "monitor"
+    ],
+    "merged_at": "2026-07-13T07:31:34.880608+00:00",
+    "updated_at": "2026-07-13T07:31:34.881584+00:00"
+  },
+  "prepare": {
+    "base_name": "安徽运八需求",
+    "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx",
+    "requirement_input_type": "docx",
+    "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md",
+    "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求",
+    "technical_solution_files": [],
+    "normalized_technical_solution_files": [],
+    "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md",
+    "document_confidence": {
+      "requirement": 0.9,
+      "issues": []
+    },
+    "activated_knowledge": {
+      "terminology": {
+        "permanent": [
+          "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md"
+        ],
+        "optional": []
+      },
+      "semantic_matches": [
+        {
+          "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md",
+          "score": 0.1155,
+          "category": "best_practice"
+        },
+        {
+          "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md",
+          "score": 0.0916,
+          "category": "history"
+        }
+      ]
+    },
+    "knowledge_gaps": [],
+    "agent_notes": {
+      "document-parser": "解析完成，置信度 90%",
+      "knowledge-activator": "激活 1 常驻 + 0 可选术语"
+    },
+    "_meta": {
+      "zone": "prepare",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.805524+00:00",
+      "status": "completed"
+    }
+  },
+  "base_name": "安徽运八需求",
+  "requirement_source_file": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\安徽运八需求.docx",
+  "requirement_input_type": "docx",
+  "normalized_requirement_file": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求\\requirement.md",
+  "normalized_dir": "E:\\test\\QaAutomationHub\\output\\normalized_inputs\\安徽运八需求",
+  "technical_solution_files": [],
+  "normalized_technical_solution_files": [],
+  "project_profile_file": "E:\\test\\QaAutomationHub\\knowledge_base\\00_project\\project_profile.md",
+  "document_confidence": {
+    "requirement": 0.9,
+    "issues": []
+  },
+  "activated_knowledge": {
+    "terminology": {
+      "permanent": [
+        "E:\\test\\QaAutomationHub\\knowledge_base\\01_standards\\terminology.md"
+      ],
+      "optional": []
+    },
+    "semantic_matches": [
+      {
+        "path": "E:\\test\\QaAutomationHub\\knowledge_base\\03_best_practices\\data_reporting_cases.md",
+        "score": 0.1155,
+        "category": "best_practice"
+      },
+      {
+        "path": "E:\\test\\QaAutomationHub\\knowledge_base\\02_history\\common_missed_scenes.md",
+        "score": 0.0916,
+        "category": "history"
+      }
+    ]
+  },
+  "knowledge_gaps": [],
+  "agent_notes": {
+    "execution-analyst": "等待测试结果输入",
+    "knowledge-curator": "等待执行分析结果"
+  },
+  "analyze": {
+    "base_name": "安徽运八需求",
+    "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md",
+    "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md",
+    "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md",
+    "related_requirements": [],
+    "conflict_candidates_count": 0,
+    "conflict_summary": {},
+    "risk_matrix": {
+      "risks": [
+        {
+          "id": "RISK-FINANCIAL",
+          "category": "资损",
+          "keywords_matched": [
+            "金额",
+            "支付"
+          ],
+          "likelihood": 2,
+          "impact": 5,
+          "score": 10,
+          "level": "P1",
+          "conflict_amplified": false
+        },
+        {
+          "id": "RISK-AVAILABILITY",
+          "category": "可用性",
+          "keywords_matched": [
+            "超时",
+            "重试"
+          ],
+          "likelihood": 2,
+          "impact": 4,
+          "score": 8,
+          "level": "P2",
+          "conflict_amplified": false
+        }
+      ],
+      "total": 2,
+      "p0_count": 0,
+      "p1_count": 1
+    },
+    "confirmation_gate": {
+      "required": false,
+      "reasons": [],
+      "pending_markers_count": 0,
+      "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md",
+      "decision_status": "not_required",
+      "decision_status_label": "已确认",
+      "allow_export_before_confirmation": true,
+      "candidate_decision_files": [
+        "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
+      ],
+      "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
+    },
+    "agent_notes": {
+      "requirement-analyzer": "识别 0 个关联需求",
+      "conflict-detector": "检测到 0 个冲突候选",
+      "risk-assessor": "识别 2 个风险项"
+    },
+    "_meta": {
+      "zone": "analyze",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.855607+00:00",
+      "status": "completed"
+    }
+  },
+  "analysis_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_分析.md",
+  "relation_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_关联与冲突.md",
+  "risk_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_风险评估.md",
+  "related_requirements": [],
+  "conflict_candidates_count": 0,
+  "conflict_summary": {},
+  "risk_matrix": {
+    "risks": [
+      {
+        "id": "RISK-FINANCIAL",
+        "category": "资损",
+        "keywords_matched": [
+          "金额",
+          "支付"
+        ],
+        "likelihood": 2,
+        "impact": 5,
+        "score": 10,
+        "level": "P1",
+        "conflict_amplified": false
+      },
+      {
+        "id": "RISK-AVAILABILITY",
+        "category": "可用性",
+        "keywords_matched": [
+          "超时",
+          "重试"
+        ],
+        "likelihood": 2,
+        "impact": 4,
+        "score": 8,
+        "level": "P2",
+        "conflict_amplified": false
+      }
+    ],
+    "total": 2,
+    "p0_count": 0,
+    "p1_count": 1
+  },
+  "confirmation_gate": {
+    "required": false,
+    "reasons": [],
+    "pending_markers_count": 0,
+    "decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md",
+    "decision_status": "not_required",
+    "decision_status_label": "已确认",
+    "allow_export_before_confirmation": true,
+    "candidate_decision_files": [
+      "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
+    ],
+    "suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
+  },
+  "design": {
+    "base_name": "安徽运八需求",
+    "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md",
+    "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md",
+    "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md",
+    "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md",
+    "p0_required_coverage": "N/A",
+    "agent_notes": {
+      "test-strategist": "策略已生成，0 个 P0 风险需 100% 覆盖",
+      "testpoint-designer": "待 AI Agent 生成测试点",
+      "case-designer": "待 AI Agent 生成用例",
+      "data-builder": "测试数据模板已生成"
+    },
+    "_meta": {
+      "zone": "design",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.874648+00:00",
+      "status": "completed"
+    }
+  },
+  "strategy_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试策略.md",
+  "test_points_file": "E:\\test\\QaAutomationHub\\output\\test_points\\安徽运八需求_测试点.md",
+  "test_cases_file": "E:\\test\\QaAutomationHub\\output\\test_cases\\安徽运八需求_测试用例.md",
+  "test_data_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_测试数据.md",
+  "p0_required_coverage": "N/A",
+  "execute": {
+    "base_name": "安徽运八需求",
+    "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py",
+    "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py",
+    "execution_report_file": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md",
+    "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求",
+    "execution_config": {
+      "browsers": [
+        "chromium",
+        "firefox",
+        "webkit"
+      ],
+      "mobile_platforms": [
+        "android",
+        "ios"
+      ],
+      "screenshot_on_failure": true,
+      "screenshot_on_step": false
+    },
+    "agent_notes": {
+      "web-executor": "Playwright 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py",
+      "mobile-executor": "Appium 脚本已生成 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py",
+      "result-reporter": "执行报告 → E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求_执行报告.md"
+    },
+    "_meta": {
+      "zone": "execute",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.877678+00:00",
+      "status": "completed"
+    }
+  },
+  "playwright_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\playwright_tests.py",
+  "appium_script": "E:\\test\\QaAutomationHub\\output\\execution\\安徽运八需求\\appium_tests.py",
+  "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md",
+  "screenshots_dir": "E:\\test\\QaAutomationHub\\output\\screenshots\\安徽运八需求",
+  "execution_config": {
+    "browsers": [
+      "chromium",
+      "firefox",
+      "webkit"
+    ],
+    "mobile_platforms": [
+      "android",
+      "ios"
+    ],
+    "screenshot_on_failure": true,
+    "screenshot_on_step": false
+  },
+  "review": {
+    "base_name": "安徽运八需求",
+    "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md",
+    "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md",
+    "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md",
+    "quality_verdict": {
+      "verdict": "BLOCKED",
+      "reason": "测试用例文件尚未生成或为空",
+      "case_count": 0,
+      "min_coverage_required": 0.95,
+      "max_blockers_allowed": 0
+    },
+    "agent_notes": {
+      "case-reviewer": "等待用例生成",
+      "coverage-auditor": "覆盖率审计待 AI Agent 执行",
+      "quality-gatekeeper": "裁决: BLOCKED"
+    },
+    "_meta": {
+      "zone": "review",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.879631+00:00",
+      "status": "completed"
+    }
+  },
+  "review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md",
+  "coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md",
+  "verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md",
+  "quality_verdict": {
+    "verdict": "BLOCKED",
+    "reason": "测试用例文件尚未生成或为空",
+    "case_count": 0,
+    "min_coverage_required": 0.95,
+    "max_blockers_allowed": 0
+  },
+  "monitor": {
+    "base_name": "安徽运八需求",
+    "execution_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_执行分析.md",
+    "agent_notes": {
+      "execution-analyst": "等待测试结果输入",
+      "knowledge-curator": "等待执行分析结果"
+    },
+    "curation_suggestions": [],
+    "_meta": {
+      "zone": "monitor",
+      "base_name": "安徽运八需求",
+      "updated_at": "2026-07-13T07:31:34.880608+00:00",
+      "status": "completed"
+    }
+  },
+  "curation_suggestions": [],
+  "current_excel_file": "E:\\test\\QaAutomationHub\\output\\excel_reports\\安徽运八需求_测试用例.xlsx",
+  "versioning_scheme": {
+    "current_files": "固定文件名，始终表示当前最新版",
+    "snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本",
+    "snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/"
+  },
+  "latest_snapshot_version": "v2",
+  "latest_snapshot_dir": "E:\\test\\QaAutomationHub\\output\\versions\\安徽运八需求\\v2",
+  "latest_snapshot_type": "full_pipeline",
+  "maintained_requirement_file": "E:\\test\\QaAutomationHub\\requirements\\安徽运八需求.md"
+}

output/versions/安徽运八需求/v3/安徽运八需求_关联与冲突.md

@@ -0,0 +1,16 @@
+# 安徽运八需求 关联需求与冲突检查
+
+## 目标需求
+- `source_docs\requirements_raw\安徽运八需求.docx`
+
+## 项目画像
+- `knowledge_base\00_project\project_profile.md`
+
+## 关联技术方案
+- 未识别到同主题技术方案文档。
+
+## 关联需求识别
+- 未识别到相似度达到阈值的历史需求文档。
+
+## 潜在冲突与修改建议
+- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。

output/versions/安徽运八需求/v3/安徽运八需求_分析.md

@@ -0,0 +1,165 @@
+# 安徽运八需求 结构化分析
+
+> 生成时间: 2026-07-13
+> 需求文档: source_docs/requirements_raw/安徽运八需求.docx
+> 项目画像: knowledge_base/00_project/project_profile.md
+
+## 1. 需求背景
+
+根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。
+
+## 2. 目标
+
+实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。
+
+## 3. 用户角色
+
+| 角色 | 职责 |
+| :--- | :--- |
+| 平台运营人员 | 查看看板、发起申诉、监控上报状态 |
+| 系统自动 | 自动触发三阶段上报和ETC上传 |
+| 财务人员 | 打款操作（触发第二次上报） |
+| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 |
+
+## 4. 功能模块
+
+### 4.1 上报运单看板
+集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。
+
+### 4.2 第一次上报（装货完成）
+运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。
+
+### 4.3 第二次上报（打款完成）
+运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。
+
+### 4.4 第三次上报（开票完成）
+发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。
+
+### 4.5 ETC发票上传
+用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。需在税务抵扣完成后进行。
+
+### 4.6 异常申诉功能
+补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。
+
+### 4.7 上报日志
+记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。
+
+## 5. 核心规则
+
+### 5.1 税源地过滤
+- 仅税源地为安徽运八的运单触发上报
+- 其他税源地（如云南=28）不触发任何上报
+
+### 5.2 上报阶段依赖链
+- 第一次上报是后续两次上报的基础
+- 第二次上报依赖第一次上报完成
+- 第三次上报依赖第二次上报完成
+- 后端必须做前置状态校验（非仅前端控制）
+
+### 5.3 自动重试机制
+- 各阶段上报失败后自动重试（最多3次）
+- 3次全部失败后告警通知运营人员
+- 重试期间禁止手动触发上传
+
+### 5.4 核验规则
+- 第二次上报包含17项核验（API文档§4.1定义），比需求的7类更为细化
+- 核验异常可通过申诉机制向监管平台说明情况
+- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口
+- 申诉由安徽监管平台复核
+
+### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2）
+
+| 接口 | URL | 方法 | 说明 |
+|:---|:---|:---:|:---|
+| 获取token | /sys/login | POST | JWT认证 |
+| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 |
+| 提交申诉运单 | /appeal/insert | POST | 发起申诉 |
+| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） |
+| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 |
+| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 |
+| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） |
+| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 |
+| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） |
+
+### 5.6 申诉状态枚举三版本对照
+
+| 需求文档 | HTML原型 | API文档(§4.4) | API Code |
+|:---|:---|:---|:---:|
+| 未申诉 | 未申诉 | 未申诉 | 100 |
+| 申诉中 | 待省平台反馈 | — | — |
+| — | 反馈处理中 | — | — |
+| 申诉通过 | 申诉通过 | 审核通过 | 110 |
+| 申诉驳回 | 申诉驳回 | 审核不通过 | 120 |
+| — | — | 已取消 | 130 |
+
+> ⚠️ **待确认**:
+> - 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？
+> - API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？
+> - API无"申诉中"状态，仅有"未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)"——申诉流程中如何进行状态管理？
+> - 看板筛选下拉值以哪个为准？
+
+## 6. 数据字段
+
+### 6.1 第一次上报核心字段
+- waybillInfo（建单信息）: 13字段（必选）
+- consignorInfo（托运人信息）: 7字段（必选）
+- consigneeInfo（收货方信息）: 5字段（必选）
+- driverInfo（司机信息）: 13字段（必选）
+- carInfo（接单车辆信息）: 19字段（必选）
+- goodsInfos（货物信息）: 4字段/条（必选，可多条）
+- insuranceInformation（保险信息）: 2字段（可选）
+
+### 6.2 第二次上报新增字段
+- 资金流水信息: 10字段（必选）
+- 车辆轨迹信息: 6字段/点（必选，2~2000个点）
+
+### 6.3 第三次上报核心字段
+- 发票信息: 17字段（必选）
+- 油气发票信息（可选，可多条）
+
+### 6.4 ETC发票核心字段
+- ETC发票信息: 18字段/张
+
+## 7. 状态流转
+
+### 7.1 上报状态
+上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色)
+
+### 7.2 申诉状态
+未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉
+
+## 8. 歧义标注与待确认项
+
+### 8.1 核验项定义差异（P0 阻断）
+> ⚠️ 待确认1: 需求文档将核验项描述为7大类，但API文档§4.1定义了17项独立核验项。测试点已按API文档17项逐项覆盖（TP-C-006~TP-C-019 保留原7类 + TP-C-026~TP-C-049 补充12项），需与产品和开发确认最终核验粒度。
+
+### 8.2 申诉状态枚举三版本不一致（P1）
+> ⚠️ 待确认2: 申诉状态在需求（未申诉/申诉中/申诉通过/申诉驳回）、原型（未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回）、API（未申诉100/审核通过110/审核不通过120/已取消130）三处不一致，需确认最终版本。详见 §5.6 对照表。
+
+### 8.3 第三次上报列表字段差异（P1）
+> ⚠️ 待确认3: 原型列表比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox），需确认最终字段列表。
+
+### 8.4 看板申诉状态下拉值差异（P1）
+> ⚠️ 待确认4: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求"未申诉/申诉中/申诉通过/申诉驳回"不一致，需确认最终版本。
+
+### 8.5 原型详情弹窗字段数量差异（P1）
+> ⚠️ 待确认5: 原型详情弹窗各分组字段数量与需求/接口文档不一致（原型大幅简化），需确认以哪个为准。
+
+### 8.6 原型缺失车辆轨迹信息（P1）
+> ⚠️ 待确认6: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？
+
+### 8.7 技术细节待确认
+> ⚠️ 待确认7: 自动重试的具体间隔时间（需求中未明确），当前假设为5s/15s/30s，需与技术方案确认。
+> ⚠️ 待确认8: ETC税额边界值（0.01元→税额=0.00）的四舍五入规则需与财务确认。
+> ⚠️ 待确认9: 申诉超时告警阈值（需求中未明确），当前假设为7个工作日，需与产品确认。
+> ⚠️ 待确认10: 安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突，需人工确认。
+> ⚠️ 待确认11: 上报接口文档密码保护（szjj@2023），字段定义以接口文档为准，需确认需求与接口文档一致性。
+> ⚠️ 待确认12: 里程申诉接口 /mileageAppeal/insert 为需求未提及的新功能，需确认是否纳入本期范围。
+> ⚠️ 待确认13: ETC发票详情含"不含税金额"字段是否需要在测试用例中体现。
+
+## 9. 项目差异化约束
+
+- 省份代码: 安徽=34（非云南=28）
+- 该需求为新增模块，与现有云南上报逻辑隔离
+- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin
+- 支付方式: arpa_2（云企付二期）

output/versions/安徽运八需求/v3/安徽运八需求_测试用例.md

@@ -0,0 +1,387 @@
+# 安徽运八需求 测试用例
+
+> 生成时间: 2026-07-13
+> 需求文档: output/normalized_inputs/安徽运八需求/requirement.md
+> 测试点来源: output/test_points/安徽运八需求_测试点.md (106个测试点)
+> 测试数据参考: output/analysis/安徽运八需求_测试数据.md
+> 关联分析: output/analysis/安徽运八需求_关联与冲突.md
+>
+> 测试用例总数: 150
+> P0: 28 / P1: 80 / P2: 34 / P3: 8
+> 模块分布: A(看板)=18, B(第一次上报)=23, C(第二次上报)=48, D(第三次上报)=15, E(ETC)=12, F(申诉)=17, G(日志)=11, X(跨模块)=7
+
+---
+
+## 模块A: 上报运单看板
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_DASH_001 | 平台端-监管上报-上报看板 | 验证看板按完整运单号精确搜索运单 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端https://ybxcx.ynyun8.com:8000/admin；2. 系统中存在运单号YB202607130001的运单记录 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入完整运单号"YB202607130001"；3. 点击搜索按钮或按回车键 | 运单号: YB202607130001 | 页面列表仅展示1条记录，运单号列显示"YB202607130001"（精确匹配）；数据库查询返回唯一记录，where条件为waybill_no='YB202607130001' | 对应TP-A-001 |
+| AH_REPORT_DASH_002 | 平台端-监管上报-上报看板 | 验证看板按运单号模糊搜索匹配多条记录 | P0 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在运单号包含"YB20260713"前缀的多条运单（如YB202607130001、YB202607130002、YB202607130003） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入"YB20260713"；3. 点击搜索 | 运单号部分字符: YB20260713 | 页面列表展示3条记录，所有运单号均包含"YB20260713"；数据库查询SQL使用LIKE '%YB20260713%'匹配，返回3条结果 | 对应TP-A-001 |
+| AH_REPORT_DASH_003 | 平台端-监管上报-上报看板 | 验证看板按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端 | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框中输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 页面列表显示空状态，提示"未找到匹配数据"或空结果占位图；数据库查询返回0条记录；页面不出现控制台报错 | 对应TP-A-001 |
+| AH_REPORT_DASH_004 | 平台端-监管上报-上报看板 | 验证看板按"第一次上报"阶段筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在不同上报阶段的运单（至少含1条第一次上报、1条第二次上报的运单） | 1. 进入"监管上报-上报看板"页面，默认为"全部"；2. 点击上报阶段下拉框，选择"第一次上报"；3. 观察列表数据 | 筛选条件: 第一次上报 | 列表仅展示上报阶段为"第一次上报"的运单；每条记录的上报阶段列均为"第一次上报"；数据库查询添加where report_stage='first'过滤条件；总条目数与数据库中第一次上报运单数一致 | 对应TP-A-002 |
+| AH_REPORT_DASH_005 | 平台端-监管上报-上报看板 | 验证看板按"异常"核验状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验状态为"通过"和"异常"的运单 | 1. 进入"监管上报-上报看板"页面；2. 点击核验状态下拉框，选择"异常"；3. 观察列表数据 | 筛选条件: 核验状态=异常 | 列表仅展示核验状态为"异常"（橙色标签）的运单；所有"通过"的运单被过滤；数据库查询添加where verification_status='abnormal'条件 | 对应TP-A-003 |
+| AH_REPORT_DASH_006 | 平台端-监管上报-上报看板 | 验证看板按"申诉中"申诉状态筛选运单 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在申诉状态为"申诉中"的运单至少1条 | 1. 进入"监管上报-上报看板"页面；2. 点击申诉状态下拉框，选择"申诉中"；3. 观察列表数据并与全部列表对比 | 筛选条件: 申诉状态=申诉中 | 列表仅展示申诉状态为"申诉中"的运单；申诉状态列标签显示"申诉中"且颜色与需求定义一致；数据库查询添加where appeal_status='in_progress'条件 | 对应TP-A-004；⚠️ 待确认: 原型看板申诉状态下拉值为"未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回"，与需求不一致 |
+| AH_REPORT_DASH_007 | 平台端-监管上报-上报看板 | 验证看板组合筛选—第二次上报+异常+申诉中+运单号模糊搜索 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在满足组合条件的运单（第二次上报、核验异常、申诉中、运单号含"YB2026"） | 1. 进入"监管上报-上报看板"页面；2. 上报阶段选"第二次上报"；3. 核验状态选"异常"；4. 申诉状态选"申诉中"；5. 运单号输入"YB2026"；6. 点击搜索 | 组合条件: 第二次上报+异常+申诉中; 运单号模糊: YB2026 | 列表仅展示同时满足4个条件的运单；每个条件都在数据库SQL中体现（多WHERE条件AND组合）；空结果时显示"未找到匹配数据"；切换任一筛选条件不丢失运单号搜索框中已输入的关键字 | 对应TP-A-005 |
+| AH_REPORT_DASH_008 | 平台端-监管上报-上报看板 | 验证看板导出当前筛选结果为Excel文件 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有≥20条运单数据 | 1. 进入"监管上报-上报看板"页面；2. 设置筛选条件（如上报阶段=第一次上报）；3. 点击"导出"按钮；4. 等待文件下载完成；5. 打开下载的Excel文件 | 筛选: 第一次上报 | 浏览器触发文件下载，文件名为.xlsx格式；Excel文件可正常打开，表头包含14个列表字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间、操作）；导出数据行数与筛选结果一致；导出过程中页面不卡死、不超时 | 对应TP-A-006 |
+| AH_REPORT_DASH_009 | 平台端-监管上报-上报看板 | 验证看板大数据量导出不超时不OOM | P2 | 性能测试 | 1. 使用super_admin账号登录管理端；2. 数据库中存在≥2000条运单记录 | 1. 进入"监管上报-上报看板"页面；2. 选择"全部"筛选条件；3. 点击"导出"按钮；4. 记录从点击到下载完成的时间 | 导出全部数据, 约2000+条 | 导出在60秒内完成下载（不超时）；导出的Excel文件包含全部数据行，无截断；后台服务内存使用率未显著增长（无OOM）；导出过程中看板页面仍可正常操作 | 对应TP-A-006 |
+| AH_REPORT_DASH_010 | 平台端-监管上报-上报看板 | 验证看板重置按钮恢复所有查询条件至默认值 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 已在上报阶段选择"第二次上报"、核验状态选择"异常"、运单号输入"YB2026" | 1. 进入"监管上报-上报看板"页面；2. 点击"重置"按钮；3. 观察页面各筛选条件和列表数据 | 重置前条件: 第二次上报+异常+YB2026 | 模糊搜索输入框清空为空白；所有下拉筛选恢复为"全部"；列表刷新展示默认全部运单数据（初始状态）；分页回到第1页；数据库查询恢复为无过滤条件的默认查询 | 对应TP-A-007 |
+| AH_REPORT_DASH_011 | 平台端-监管上报-上报看板 | 验证看板列表展示14个字段且顺序与需求一致 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在至少1条完整运单记录 | 1. 进入"监管上报-上报看板"页面；2. 查看列表表头和第一条数据的各列内容；3. 对比需求文档中的字段顺序 | 查看运单YB202607130001 | 列表14个字段顺序为: 货源单号→运单号→托运单号→车牌号→司机姓名→托运方名称→上报阶段→核验状态→申诉状态→异常项→货物名称→合同金额→最新核验时间→操作；合同金额列保留2位小数（如¥10,000.00）；最新核验时间为YYYY-MM-DD HH:mm:ss格式；异常项为空时显示"-"而非"null"或"undefined" | 对应TP-A-008 |
+| AH_REPORT_DASH_012 | 平台端-监管上报-上报看板 | 验证看板状态标签颜色—蓝色(上传中)、绿色(已上传)、红色(上传失败)、橙色(异常) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在4种上报状态的运单各1条 | 1. 进入"监管上报-上报看板"页面；2. 找到上报状态为"上传中"的运单，查看标签颜色；3. 找到"已上传"运单，查看标签颜色；4. 找到"上传失败"运单，查看标签颜色；5. 找到"异常"运单，查看标签颜色 | 运单1: 上传中; 运单2: 已上传; 运单3: 上传失败; 运单4: 异常 | "上传中"标签显示蓝色背景/文字；"已上传"标签显示绿色背景/文字；"上传失败"标签显示红色背景/文字；"异常"标签显示橙色背景/文字；状态切换时标签颜色即时刷新不闪烁；申诉状态标签（申诉中/申诉通过/申诉驳回）颜色各自区分清晰 | 对应TP-A-009 |
+| AH_REPORT_DASH_013 | 平台端-监管上报-上报看板 | 验证看板操作列—异常运单显示申诉按钮、所有运单显示详情按钮 | P1 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 系统中存在核验通过的运单1条和核验异常的运单1条 | 1. 进入"监管上报-上报看板"页面；2. 查看核验通过运单的操作列按钮；3. 查看核验异常运单的操作列按钮；4. 点击异常运单的"申诉"按钮 | 通过运单: YB202607130001; 异常运单: YB202607130002 | 核验通过运单的操作列显示"详情"和"进度"按钮，不显示"申诉"按钮；核验异常运单的操作列显示"申诉""详情""进度"三个按钮；点击"申诉"按钮后页面路由跳转至申诉页面，URL携带正确的运单ID参数；点击"详情"按钮弹出详情弹窗，展示该运单的完整上报信息 | 对应TP-A-010 |
+| AH_REPORT_DASH_014 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—建单信息分组13字段完整 | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有可查看详情的运单YB202607130001 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001操作列的"详情"按钮；3. 在弹窗中查看"建单信息"分组的所有字段 | 运单号: YB202607130001 | 建单信息分组展示13个字段: 上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号（必选）、委托合同编号（可选）、运输里程（可选）；必选字段均有值；可选字段委托合同编号和运输里程为空时显示"-"；各字段格式与接口规范一致 | 对应TP-A-011 |
+| AH_REPORT_DASH_015 | 平台端-监管上报-上报看板 | 验证看板详情弹窗—各子对象分组字段完整(托运人/收货方/司机/车辆/货物) | P2 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板列表中有运单YB202607130001包含完整的子对象信息 | 1. 进入"监管上报-上报看板"页面；2. 点击运单YB202607130001的"详情"按钮；3. 依次展开托运人信息、收货方信息、司机信息、车辆信息、货物信息分组 | 运单号: YB202607130001; 司机: 15188888888 | 托运人信息7字段完整（含统一社会信用代码18位格式校验）；收货方信息5字段完整（身份证号如适用需脱敏展示）；司机信息13字段完整（从业资格证有效期起止日期格式正确）；车辆信息19字段完整（VIN码17位正确展示）；货物信息支持多条记录展开，每条含货物名称、货物类型代码、货物量、计量单位；可选字段为空时显示"-" | 对应TP-A-011 |
+| AH_REPORT_DASH_016 | 平台端-监管上报-上报看板 | 验证看板空数据状态展示友好占位提示 | P3 | 易用性测试 | 1. 使用super_admin账号登录管理端；2. 选择一个筛选条件组合确保结果为0条（如运单号输入"ZZZZZZZZZZ"） | 1. 进入"监管上报-上报看板"页面；2. 在运单号搜索框输入"ZZZZZZZZZZ"；3. 点击搜索 | 运单号: ZZZZZZZZZZ | 列表区域显示友好空状态占位图/文，不显示空白表格；有明确文字提示"未找到匹配数据"或类似文案；浏览器开发者工具Console无报错；页面无崩溃或白屏 | 对应TP-A-012 |
+| AH_REPORT_DASH_017 | 平台端-监管上报-上报看板 | 验证看板分页功能—翻页数据不重复不遗漏 | P3 | 功能测试 | 1. 使用super_admin账号登录管理端；2. 看板中有超过20条运单（默认每页20条） | 1. 进入"监管上报-上报看板"页面，记录第1页的运单号列表；2. 点击"下一页"进入第2页；3. 记录第2页的运单号列表；4. 对比两页数据；5. 查看分页组件显示的总条数 | 每页20条 | 第1页和第2页的运单号无重复；第2页首条数据不是第1页已出现的数据；切换每页条数（如50条/页）后分页重新计算正确；分页组件显示的总条数与数据库COUNT查询结果一致；数据按最新核验时间倒序排列（最近核验的在最前面） | 对应TP-A-013 |
+| AH_REPORT_DASH_018 | 平台端-监管上报-上报看板 | 验证不同角色看板权限—运营可见全部/财务可见打款字段/司机不可见平台端看板 | P1 | 安全性测试 | 1. 准备super_admin账号(运营)、财务账号、车队长账号13113113113、司机账号15188888888；2. 系统中存在运单数据 | 1. 使用super_admin登录，进入看板，验证可见全部运单和全部字段；2. 使用财务账号登录，进入看板，验证可见运单范围和打款相关字段；3. 使用车队长13113113113登录司机端，验证是否有看板入口；4. 使用司机15188888888登录司机端，验证是否有看板入口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113/88888888; 司机: 15188888888/88888888 | super_admin可见全部运单和全部14个字段；财务可见运单但打款金额/付款方式/收款账号类型等字段可见；车队长登录司机端后无"监管上报-上报看板"菜单入口，直接URL访问被拦截返回403；司机登录司机端后同样无看板入口，越权访问被拦截并记录审计日志 | 对应TP-A-014 |
+
+---
+
+## 模块B: 第一次上报-装货完成
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_R1_001 | 平台端-监管上报-第一次上报 | 验证装货完成后自动触发第一次上报且全部子对象数据完整 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条安徽税源地(provinceCode=34)的运单YB202607130001，状态为"待装货"；3. 运单包含完整的托运人、收货方、司机、车辆、货物信息 | 1. 司机到达装货地，上传装货照片和资料；2. 司机在APP端点击"确认装货完成"；3. 等待系统自动触发第一次上报；4. 使用super_admin登录管理端，进入"监管上报-第一次上报"列表查看该运单上报状态 | 运单号: YB202607130001; 司机: 15188888888; 装货地省份代码: 34 | 司机端提示"装货完成，上报已提交"；管理端第一次上报列表中出现该运单记录，上报状态为"上传中"（蓝色标签），随后变为"已上传"（绿色标签）；上报请求JSON包含全部7个子对象(建单信息/托运人/收货方/司机/车辆/货物/保险)；数据库report_record表status字段从0变为1，上报时间字段非空 | 对应TP-B-001 |
+| AH_REPORT_R1_002 | 平台端-监管上报-第一次上报 | 验证非安徽税源地运单(云南=28)装货完成后不触发第一次上报 | P0 | 功能测试 | 1. 使用司机账号15188888888登录司机端APP；2. 存在一条云南税源地(provinceCode=28)的运单YB202607130002，状态为"待装货" | 1. 司机完成装货并点击"确认装货完成"；2. 检查管理端"监管上报-第一次上报"列表；3. 检查系统日志是否有上报请求记录 | 运单号: YB202607130002; 省份代码: 28(云南) | 管理端第一次上报列表中不出现该运单记录；系统日志中无该运单的上报接口调用记录；运单状态正常流转为"运输中"，不受上报模块影响；无任何错误日志或异常告警产生 | 对应TP-B-002 |
+| AH_REPORT_R1_003 | 平台端-监管上报-第一次上报 | 验证安徽税源地运单(省份代码=34)触发上报，其他省份不触发 | P0 | 功能测试 | 1. 准备安徽(34)、云南(28)、四川(51)税源地的运单各1条；2. 三条运单状态均为"待装货" | 1. 分别对三条运单确认装货完成；2. 进入管理端第一次上报列表查看；3. 查询数据库report_record表 | 安徽运单: provinceCode=34; 云南运单: provinceCode=28; 四川运单: provinceCode=51 | 仅安徽(34)运单在第一次上报列表中出现，上报状态正常更新；云南(28)和四川(51)运单均不在列表中；数据库report_record表仅新增1条记录，province_code=34 | 对应TP-B-002; TP-B-004 |
+| AH_REPORT_R1_004 | 平台端-监管上报-第一次上报 | 验证第一次上报建单信息必选字段缺失时上报被拒绝并明确提示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条建单信息中"承运合同编号"为空的运单YB202607130003 | 1. 触发该运单装货完成事件（模拟或真实操作）；2. 查看第一次上报返回结果；3. 查看上报日志中的错误信息 | 运单号: YB202607130003; 缺失字段: 承运合同编号 | 上报接口返回错误，提示"必选字段承运合同编号不能为空"或类似明确消息；上报状态标记为"上传失败"（红色标签）；上报日志中记录该次失败请求，包含请求体和错误响应体；运单状态不会错误地标记为"已上传" | 对应TP-B-003 |
+| AH_REPORT_R1_005 | 平台端-监管上报-第一次上报 | 验证第一次上报统一社会信用代码格式校验（非18位时拒绝） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 构造一条运单，托运人统一社会信用代码为"123456"（6位无效格式） | 1. 触发该运单装货完成事件；2. 查看上报接口返回；3. 查看上报日志 | 运单号: YB202607130004; 信用代码: 123456(无效) | 上报接口返回校验错误，提示"统一社会信用代码格式不正确，需为18位"；上报状态标记为"上传失败"；不会错误地将无效代码上报至监管平台 | 对应TP-B-003 |
+| AH_REPORT_R1_006 | 平台端-监管上报-第一次上报 | 验证第一次上报中司机信息省份代码为安徽=34（非云南=28） | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备一条安徽税源地(34)的完整运单YB202607130001 | 1. 触发的第一次上报完成后；2. 在上报日志中查看该次上报的完整请求JSON；3. 定位司机信息(driverInfo)中的provinceCode字段值 | 运单号: YB202607130001; 期望省份代码: 34 | 请求JSON中driverInfo.provinceCode="34"；不会出现值"28"；装货地行政区划代码前2位也为"34"（安徽省代码340000）；数据库/Redis/配置文件中无硬编码省份代码28 | [AI修正: 历史缺陷防御] - BUG-202607-04 |
+| AH_REPORT_R1_007 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后第二次上报接口被拒绝并返回错误码"前置上报未完成" | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"（3次重试均失败）；2. 财务已完成打款（触发第二次上报的条件已满足） | 1. 通过API直接调用第二次上报接口（或模拟打款完成回调触发）；2. 查看接口返回的HTTP状态码和错误消息 | 运单号: YB202607130005 | 接口返回错误码（如HTTP 400或业务错误码"PRE_STAGE_NOT_COMPLETED"），错误消息包含"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中该运单上报状态未变更，不会出现"上传中"或"已上传"；数据库report_record表无第二次上报的新记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_R1_008 | 平台端-监管上报-第一次上报 | 验证第一次上报自动重试3次全部失败后第三次上报同样被拒绝 | P0 | 功能测试 | 1. 运单YB202607130006第一次上报3次重试全部失败；2. 第二次上报也未完成 | 1. 通过API直接调用第三次上报接口；2. 查看接口返回 | 运单号: YB202607130006 | 接口返回错误码，明确标识"前置上报（第一次）未完成"；后端通过查询运单上报状态表(如report_status)做校验，非仅依赖前端布尔值；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_R1_009 | 平台端-监管上报-第一次上报 | 验证第一次上报成功后监管平台核验通过时自动调用修改字段接口 | P1 | 功能测试 | 1. 运单YB202607130001第一次上报成功且状态为"已上传"；2. 模拟监管平台返回核验通过 | 1. 等待或模拟监管平台核验通过回调；2. 查看上报日志中是否有"修改第一次上报部分字段"的接口调用记录；3. 查看修改后的字段值 | 运单号: YB202607130001; 实际运输里程: 158.5km（装货后变化值） | 上报日志中出现"修改字段"接口调用记录；修改的字段包含实际运输里程等装货后变化字段；修改成功后第一次上报状态仍保持"已上传"（绿色）；若修改接口调用失败，有重试和告警机制 | 对应TP-B-006 |
+| AH_REPORT_R1_010 | 平台端-监管上报-第一次上报 | 验证第一次上报失败后自动重试最多3次且间隔递增 | P1 | 功能测试 | 1. 运单YB202607130007第一次上报时模拟监管平台返回失败 | 1. 触发第一次上报；2. 监控上报日志中的重试记录和时间间隔；3. 等待3次重试全部完成 | 运单号: YB202607130007; 重试间隔: 5s/15s/30s（参考值） | 第1次上报失败后自动触发第2次（间隔约5s）；第2次失败后触发第3次（间隔约15s）；第3次失败后触发第4次（即总共3次重试，间隔约30s）；3次重试全部失败后上报状态变为"上传失败"（红色标签），停止重试；上报日志中每1次请求（含重试）均有独立日志记录 | 对应TP-B-007 |
+| AH_REPORT_R1_011 | 平台端-监管上报-第一次上报 | 验证第一次上报3次重试全部失败后通知运营人员 | P1 | 功能测试 | 1. 运单YB202607130008第一次上报3次重试均失败；2. super_admin账号可接收站内信 | 1. 等待3次重试全部失败；2. 使用super_admin登录管理端，查看站内信/消息通知；3. 点击通知中的链接 | 运单号: YB202607130008; 失败原因: 监管平台连接超时 | super_admin收到站内信通知，标题含"上报失败"标记；通知内容包含运单号YB202607130008、失败原因"连接超时"、失败时间；点击通知中的链接可直接跳转到该运单对应的上报详情页 | 对应TP-B-008 |
+| AH_REPORT_R1_012 | 平台端-监管上报-第一次上报 | 验证上传失败状态下运营人员可点击手动上传按钮重新发起上报 | P1 | 功能测试 | 1. 运单YB202607130009上报状态为"上传失败"（红色标签）；2. 使用super_admin登录管理端 | 1. 进入"监管上报-第一次上报"列表；2. 找到YB202607130009，查看操作列；3. 点击"手动上传"按钮；4. 确认上传；5. 等待上传完成 | 运单号: YB202607130009 | 操作列显示"手动上传"按钮（仅上传失败状态可见）；点击后发起新的上报请求；上传成功后状态从"上传失败"（红色）变为"已上传"（绿色）；手动上传记录出现在上报日志中，标注操作人为"super_admin" | 对应TP-B-009 |
+| AH_REPORT_R1_013 | 平台端-监管上报-第一次上报 | 验证自动重试期间点击手动上传时系统提示"上报处理中"并拒绝重复提交 | P0 | 功能测试 | 1. 运单YB202607130010第一次上报正在自动重试中（第1次已失败，第2次进行中）；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，找到该运单；2. 等待自动重试进行中时，快速点击"手动上传"按钮 | 运单号: YB202607130010 | 前端弹出提示"上报处理中，请勿重复操作"或按钮被置灰不可点击；后端返回"上报处理中"错误（分布式锁检测到正在进行中的上报）；数据库report_record表中该运单不会产生第2条上报记录；最终仅有1条上报记录（自动重试完成后产生） | [AI修正: 历史缺陷防御] - BUG-202607-02 |
+| AH_REPORT_R1_014 | 平台端-监管上报-第一次上报 | 验证同一运单同一阶段快速连续点击手动上传仅发起1次请求 | P0 | 功能测试 | 1. 运单YB202607130011上报状态为"上传失败"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表；2. 快速连续点击"手动上传"按钮5次（模拟前端未做防抖的情况或快速双击）；3. 查看上报日志中实际发出的请求次数 | 运单号: YB202607130011; 快速点击5次 | 上报日志中仅记录1次上报请求（前端防抖+后端幂等键控制）；数据库report_record表仅产生1条新的上报记录；后端分布式锁或唯一约束（如运单号+阶段号）防止并发插入重复记录 | [AI修正: 历史缺陷防御] - BUG-202607-02 |
+| AH_REPORT_R1_015 | 平台端-监管上报-第一次上报 | 验证第一次上报接口超时(>30s)后转为上传失败并触发重试 | P1 | 功能测试 | 1. 运单YB202607130012准备上报；2. 通过工具模拟监管平台接口响应延迟>30秒 | 1. 触发第一次上报；2. 观察前端页面Loading状态；3. 等待超时后的系统处理 | 运单号: YB202607130012; 超时阈值: 30s | 前端页面显示Loading加载状态并持续至超时；超时后上报状态变为"上传失败"（红色标签）；前端页面超时后有友好提示"上报超时，系统将自动重试"；系统自动触发第1次重试；数据库report_record表中记录超时状态 | 对应TP-B-015 |
+| AH_REPORT_R1_016 | 平台端-监管上报-第一次上报 | 验证弱网环境(高延迟高丢包)下第一次上报重试机制正常工作 | P2 | 功能测试 | 1. 通过Charles/Fiddler或网络模拟工具设置网络延迟2000ms、丢包率30%；2. 运单YB202607130013待上报 | 1. 在弱网条件下触发第一次上报；2. 观察上报请求发送和响应情况；3. 等待重试或恢复 | 运单号: YB202607130013; 网络延迟: 2000ms; 丢包率: 30% | 请求发送成功但响应延迟时不立即判定失败（超时阈值30s）；弱网恢复后若重试成功则状态正常流转为"已上传"；断网时上报请求发送失败的提示友好明确；不论弱网还是正常网络，数据不会出现不一致或重复 | 对应TP-B-016 |
+| AH_REPORT_R1_017 | 平台端-监管上报-第一次上报 | 验证10个运单同时装货完成时并发上报互不干扰 | P2 | 性能测试 | 1. 准备10条安徽税源地(34)的运单YB202607130014~YB202607130023，状态均为"待装货" | 1. 通过脚本同时触发10条运单的装货完成事件；2. 监控数据库和上报日志；3. 验证每条运单的上报状态 | 10条运单同时装货完成 | 10条运单各自独立触发上报，无相互阻塞；数据库无死锁(deadlock)异常；上报日志中每条运单独立记录其上报请求和响应；每条运单的上报状态独立正确更新 | 对应TP-B-017 |
+| AH_REPORT_R1_018 | 平台端-监管上报-第一次上报 | 验证第一次上报可选字段（委托合同编号/运输里程/挂车牌照号等）为空时正常上报 | P3 | 功能测试 | 1. 准备一条运单YB202607130024，可选字段全部留空：委托合同编号、运输里程、挂车牌照号、行驶证档案编号、道路运输证有效期起/至、保险单号、保险公司名称 | 1. 触发该运单装货完成事件；2. 查看上报结果；3. 查看上报请求JSON和详情弹窗 | 运单号: YB202607130024; 可选字段全为空 | 上报接口不报错，上报成功；请求JSON中可选字段值为null或不传均可正常处理；管理端详情弹窗中可选字段显示"-"而非"null"或"undefined" | 对应TP-B-018 |
+| AH_REPORT_R1_019 | 平台端-监管上报-第一次上报 | 验证运单包含1条货物记录时正常上报 | P3 | 功能测试 | 1. 准备运单YB202607130025，仅含1条货物：货物名称"钢材"、货物类型代码"01"、货物量"10.5"、计量单位"吨" | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组；3. 查看详情弹窗货物信息展示 | 运单号: YB202607130025; 货物: 钢材 10.5吨 | goodsInfos数组包含1个元素，4个字段完整；详情弹窗中货物信息分组正确展示1条记录 | 对应TP-B-019 |
+| AH_REPORT_R1_020 | 平台端-监管上报-第一次上报 | 验证运单包含5条货物记录时各货物独立完整上报 | P3 | 功能测试 | 1. 准备运单YB202607130026，含5条货物记录：钢材10.5吨、水泥20吨、砂石15吨、砖块5000块、木材8立方 | 1. 触发装货完成；2. 查看上报请求JSON中goodsInfos数组长度和内容；3. 查看详情弹窗中多条货物的展示 | 运单号: YB202607130026; 货物: 5条 | goodsInfos数组包含5个元素；每条货物独立完整，互不影响；详情弹窗中货物信息支持展开/折叠展示5条记录；每条货物名称、类型代码、货物量、计量单位均正确 | 对应TP-B-019 |
+| AH_REPORT_R1_021 | 平台端-监管上报-第一次上报 | 验证第一次上报业务类型代码和运输组货方式代码为有效枚举值 | P1 | 功能测试 | 1. 准备运单YB202607130027，业务类型代码为"1"(普通货运)、运输组货方式代码为"10"(道路货运) | 1. 触发装货完成上报；2. 查看上报请求JSON中waybillInfo的businessTypeCode和transportGroupModeCode字段值；3. 模拟提交无效枚举值（如"99"），验证拒绝 | 运单号: YB202607130027; businessTypeCode: 1; transportGroupModeCode: 10 | 有效枚举值上报成功；无效枚举值（如businessTypeCode="99"）上报时接口返回校验错误，明确提示"业务类型代码无效"；不会将无效枚举值上报至监管平台 | 对应TP-B-003 |
+| AH_REPORT_R1_022 | 平台端-监管上报-第一次上报 | 验证第一次上报详情弹窗—异常信息分组展示核验状态/异常原因/异常时间/处理状态 | P2 | 功能测试 | 1. 运单YB202607130028第一次上报核验状态为"异常"；2. 使用super_admin登录管理端 | 1. 进入第一次上报列表，点击运单YB202607130028的"详情"按钮；2. 查看弹窗中"异常信息"分组的4个字段 | 运单号: YB202607130028; 异常原因示例: 司机资质核验不通过 | 异常信息分组包含: 核验状态（显示"异常"）、异常原因（如"司机从业资格证已过期"）、异常时间（显示实际核验时间）、处理状态（如"未申诉"）；核验通过时异常原因为空 | 对应TP-B-013 |
+| AH_REPORT_R1_023 | 平台端-监管上报-第一次上报 | 验证第一次上报状态标签颜色：上传中=蓝色、已上传=绿色、上传失败=红色、异常=橙色 | P2 | 功能测试 | 1. 准备4条运单各处于不同上报状态 | 1. 进入第一次上报列表；2. 依次查看4种状态运单的标签颜色 | 运单A: 上传中; 运单B: 已上传; 运单C: 上传失败; 运单D: 异常 | 上传中=蓝色标签+加载动画；已上传=绿色标签；上传失败=红色标签；异常=橙色标签；状态切换时标签颜色即时更新不闪烁 | 对应TP-B-010 |
+| AH_REPORT_R1_024 | 平台端-监管上报-第一次上报 | 验证第一次上报列表14个字段完整展示且顺序正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第一次上报列表中有至少1条完整记录 | 1. 进入"监管上报-第一次上报"列表；2. 查看列表表头和第一条数据的所有列内容；3. 验证每个字段的展示格式 | 运单号: YB202607130001; 运输里程: 350km; 合同编号: HT202607001 | 列表展示14个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/业务类型/货物名称/装货地址/卸货地址/运输里程/合同编号/上报状态/操作；业务类型与数据字典中枚举值一致；装货地址和卸货地址完整展示（省市区+详细地址）；运输里程带单位km；上报状态标签颜色符合规范（上传中=蓝色/已上传=绿色/上传失败=红色/异常=橙色）；列表按上报时间倒序排列 | 对应TP-B-020；[AI修正: 覆盖缺口补充] |
+
+---
+
+## 模块C: 第二次上报-打款完成
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_R2_001 | 平台端-监管上报-第二次上报 | 验证财务打款完成后自动触发第二次上报且包含资金流水和车辆轨迹信息 | P0 | 功能测试 | 1. 运单YB202607130001已完成第一次上报且状态为"已上传"；2. 财务在账户管理模块对该运单执行打款操作，金额¥10,000.00 | 1. 财务完成打款操作；2. 系统收到打款完成回调；3. 进入管理端"监管上报-第二次上报"列表查看 | 运单号: YB202607130001; 打款金额: ¥10,000.00; 付款方式: 光大银行 | 第二次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+资金流水信息+车辆轨迹信息三个模块；数据库report_record表新增第二次上报记录，stage=2 | 对应TP-C-001 |
+| AH_REPORT_R2_002 | 平台端-监管上报-第二次上报 | 验证第二次上报资金流水数据来源于支付流水表（非运单缓存） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 支付流水表实际打款金额¥10,000.00；3. 财务已打款完成 | 1. 触发第二次上报；2. 查询上报日志中的请求JSON；3. 对比请求中的金额与运单表合同金额、支付流水表打款金额；4. 检查数据库查询SQL日志确认数据来源 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 支付流水实际打款: ¥10,000.00 | 上报数据中的金额与支付流水表实际打款金额¥10,000.00完全一致；数据库查询SQL日志显示数据源为payment_flow表，非waybill表或Redis缓存；金额精确到分（2位小数），¥10,000.00无精度丢失 | [AI修正: 历史缺陷防御] - BUG-202607-03 |
+| AH_REPORT_R2_003 | 平台端-监管上报-第二次上报 | 验证财务修改打款金额后第二次上报使用最新金额（非缓存合同金额） | P0 | 功能测试 | 1. 运单YB202607130001合同金额¥10,000.00；2. 财务在账户管理模块调账将打款金额修改为¥9,500.00；3. 财务执行打款 | 1. 财务修改打款金额（¥10,000.00→¥9,500.00）；2. 财务完成打款；3. 触发第二次上报；4. 查看上报请求中的金额字段 | 运单号: YB202607130001; 合同金额: ¥10,000.00; 修改后打款金额: ¥9,500.00 | 上报请求中的金额为¥9,500.00（修改后的值），非¥10,000.00（合同金额）；上报日志中可溯源金额来源为支付流水表；不会使用装货完成时缓存的合同金额¥10,000.00 | [AI修正: 历史缺陷防御] - BUG-202607-03 |
+| AH_REPORT_R2_004 | 平台端-监管上报-第二次上报 | 验证第二次上报列表17个字段完整且收款账号类型标签颜色正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第二次上报列表中有至少2条数据（一条个人账户、一条对公账户） | 1. 进入"监管上报-第二次上报"列表；2. 查看列表表头和第一条数据的各列内容；3. 查看收款账号类型列的标签颜色 | 运单A: 个人账户(司机银行卡); 运单B: 对公账户(企业账号) | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作；承运运费和总金额保留2位小数；付款时间为实际财务打款时间；个人账户显示蓝色标签，对公账户显示绿色标签 | 对应TP-C-004; TP-C-005 |
+| AH_REPORT_R2_005 | 平台端-监管上报-第二次上报 | 验证运单重复核验—首次上报的运单核验通过 | P0 | 功能测试 | 1. 运单YB202607130001为首次进行第二次上报，此前未在任何阶段重复上报 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001(首次上报) | 核验状态标记为"通过"（绿色标签）；异常项列中无"运单重复核验"异常记录；监管平台返回的核验结果中duplicateCheck=pass；数据库运单核验记录表verification_result中duplicate_check_status='pass' | 对应TP-C-006 |
+| AH_REPORT_R2_006 | 平台端-监管上报-第二次上报 | 验证运单重复核验—重复上报检测到异常并标注异常项 | P0 | 功能测试 | 1. 运单YB202607130001已成功完成第二次上报和核验；2. 模拟或真实触发该运单的第二次重复上报 | 1. 通过API再次调用第二次上报接口（使用同一运单号YB202607130001）；2. 等待监管平台核验结果返回 | 运单号: YB202607130001(重复上报) | 核验状态变为"异常"（橙色标签）；异常项列明确标注"运单重复核验"；异常原因可读（如"该运单已存在有效上报记录"）；该异常运单可触发申诉流程，"申诉"按钮可见可用 | 对应TP-C-007 |
+| AH_REPORT_R2_007 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的车辆道路运输证有效期起: 2025-01-01, 有效期至: 2027-01-01（当前日期2026-07-13在有效期内）；2. 车辆审核状态为"通过" | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130001; 道路运输证有效期: 2025-01-01~2027-01-01 | 核验状态为"通过"；无"车辆资质核验"异常项；监管平台返回vehicleQualCheck=pass；数据库verification_result.vehicle_qual_status='pass' | 对应TP-C-008 |
+| AH_REPORT_R2_008 | 平台端-监管上报-第二次上报 | 验证车辆资质核验—道路运输证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130029关联的车辆道路运输证有效期至: 2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130029; 道路运输证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"（橙色标签）；异常项列标注"车辆资质核验"；异常原因描述如"道路运输证已过期（有效期至2025-12-31）"；该异常运单可发起申诉 | 对应TP-C-009 |
+| AH_REPORT_R2_009 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证在有效期内核验通过 | P1 | 功能测试 | 1. 运单YB202607130001关联的司机从业资格证有效期起: 2024-06-01, 有效期至: 2028-06-01（在有效期内）；2. 司机审核状态为"通过" | 1. 触发第二次上报；2. 等待核验结果；3. 查看核验状态 | 运单号: YB202607130001; 从业资格证: 有效期内 | 核验状态为"通过"；无"司机资质核验"异常项；监管平台返回driverQualCheck=pass | 对应TP-C-010 |
+| AH_REPORT_R2_010 | 平台端-监管上报-第二次上报 | 验证司机资质核验—从业资格证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130030关联的司机从业资格证有效期至: 2025-01-01（已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果；3. 查看异常项 | 运单号: YB202607130030; 从业资格证有效期至: 2025-01-01(已过期) | 核验状态变为"异常"；异常项标注"司机资质核验"；异常原因如"司机从业资格证已过期"；可发起申诉 | 对应TP-C-011 |
+| AH_REPORT_R2_011 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方为平台统一账户时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001打款付款方为网货平台统一账户；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 付款方: 网货平台统一账户 | 核验状态为"通过"；无"集中支付核验"异常项；监管平台返回centralPayCheck=pass；支付流水记录与集中支付模式匹配 | 对应TP-C-012 |
+| AH_REPORT_R2_012 | 平台端-监管上报-第二次上报 | 验证集中支付核验—付款方非平台统一账户时核验异常 | P1 | 功能测试 | 1. 运单YB202607130031打款付款方为非平台统一账户（如第三方代付账户）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130031; 付款方: 第三方代付账户(非平台) | 核验状态变为"异常"；异常项标注"集中支付核验"；异常原因如"付款方非集中支付账户"；可发起申诉 | 对应TP-C-013 |
+| AH_REPORT_R2_013 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号唯一且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001资金流水号唯一（如PAY202607130001）；2. 上报金额¥10,000.00与支付流水表实际打款金额完全一致 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 流水号: PAY202607130001; 金额: ¥10,000.00 | 核验状态为"通过"；无"资金流水核验"异常项；监管平台返回fundFlowCheck=pass | 对应TP-C-014 |
+| AH_REPORT_R2_014 | 平台端-监管上报-第二次上报 | 验证资金流水核验—流水号重复时核验异常 | P1 | 功能测试 | 1. 运单YB202607130032使用的资金流水号与已有运单的流水号重复（如均使用PAY202607130001） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130032; 重复流水号: PAY202607130001 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"流水号重复"提示；可发起申诉 | 对应TP-C-015 |
+| AH_REPORT_R2_015 | 平台端-监管上报-第二次上报 | 验证资金流水核验—上报金额与支付流水偏差>0.01元时核验异常 | P1 | 功能测试 | 1. 运单YB202607130033支付流水表实际打款¥9,500.00，但上报时发送¥10,000.00（偏差¥500.00>¥0.01） | 1. 触发第二次上报（携带错误金额）；2. 等待核验结果 | 运单号: YB202607130033; 上报金额: ¥10,000.00; 支付流水实际: ¥9,500.00 | 核验状态变为"异常"；异常项标注"资金流水核验"；异常原因包含"金额不匹配"提示；可发起申诉 | 对应TP-C-015 |
+| AH_REPORT_R2_016 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同和委托合同均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001承运合同编号CTC202607001有效（存在于合同管理系统，有效期覆盖运单执行日期2026-07-10~2026-07-13）；2. 委托合同编号DLC202607001有效（如适用） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130001; 承运合同: CTC202607001(有效); 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"合同核验"异常项；监管平台返回contractCheck=pass | 对应TP-C-016 |
+| AH_REPORT_R2_017 | 平台端-监管上报-第二次上报 | 验证合同核验—承运合同不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130034关联的承运合同编号INVALID_CTC999不存在于合同管理系统 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130034; 承运合同: INVALID_CTC999(不存在) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"承运合同不存在"提示；可发起申诉 | 对应TP-C-017 |
+| AH_REPORT_R2_018 | 平台端-监管上报-第二次上报 | 验证合同核验—合同有效期不覆盖运单执行日期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130035执行日期为2026-07-10~2026-07-13，但关联的承运合同有效期至2026-06-30（已过期不覆盖运单执行日期） | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130035; 承运合同有效期: ~2026-06-30(不覆盖运单日期) | 核验状态变为"异常"；异常项标注"合同核验"；异常原因包含"合同已过期"或"合同有效期不覆盖运单执行日期"；可发起申诉 | 对应TP-C-017 |
+| AH_REPORT_R2_019 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点≥2且≤2000且路线匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130001车辆GPS轨迹包含500个有效轨迹点；2. 轨迹路线与装货地→卸货地路线基本一致；3. 轨迹时间与运单执行时间匹配 | 1. 触发第二次上报（携带500点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130001; 轨迹点数: 500 | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；监管平台返回trackCheck=pass | 对应TP-C-018 |
+| AH_REPORT_R2_020 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130036车辆GPS轨迹仅包含2个有效轨迹点（起终点，边界最小值） | 1. 触发第二次上报（携带2点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130036; 轨迹点数: 2(边界最小值) | 核验状态为"通过"；无"车辆轨迹合规核验"异常项；边界值2个点被正确处理 | 对应TP-C-018 |
+| AH_REPORT_R2_021 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点边界值2000个点时核验通过 | P2 | 功能测试 | 1. 运单YB202607130037车辆GPS轨迹包含恰好2000个有效轨迹点（边界最大值） | 1. 触发第二次上报（携带2000点轨迹数据）；2. 等待核验结果；3. 验证2000点数据完整传输 | 运单号: YB202607130037; 轨迹点数: 2000(边界最大值) | 核验状态为"通过"；2000个轨迹点全部成功上报，无截断；页面响应不卡顿 | 对应TP-C-018 |
+| AH_REPORT_R2_022 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点<2个(仅1个点)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130038车辆GPS轨迹仅包含1个有效轨迹点 | 1. 触发第二次上报（携带1点轨迹数据）；2. 等待核验结果 | 运单号: YB202607130038; 轨迹点数: 1(不足) | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹点数量不足（至少需要2个点）"；可进入"补传轨迹"流程 | 对应TP-C-019 |
+| AH_REPORT_R2_023 | 平台端-监管上报-第二次上报 | 验证车辆轨迹合规核验—轨迹点=0(无轨迹数据)时核验异常 | P1 | 功能测试 | 1. 运单YB202607130039无GPS轨迹数据（轨迹点=0） | 1. 触发第二次上报（轨迹数据为空）；2. 等待核验结果 | 运单号: YB202607130039; 轨迹点数: 0 | 核验状态变为"异常"；异常项标注"车辆轨迹合规核验"；异常原因包含"轨迹数据缺失"；可进入"补传轨迹"流程 | 对应TP-C-019 |
+| AH_REPORT_R2_024 | 平台端-监管上报-第二次上报 | 验证第二次上报依赖第一次上报完成—第一次上报失败时第二次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130005第一次上报状态为"上传失败"；2. 财务对该运单完成打款操作 | 1. 打款完成回调触发第二次上报；2. 查看第二次上报接口返回；3. 查看第二次上报列表 | 运单号: YB202607130005(第一次上报失败) | 第二次上报接口返回错误，错误码标识"前置上报未完成"或"请先完成第一次上报"；第二次上报列表中无该运单记录或状态未更新；后端通过查询report_status表校验第一次上报完成状态；错误消息清晰可理解 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_R2_025 | 平台端-监管上报-第二次上报 | 验证第二次上报幂等性—自动重试期间禁止手动触发 | P0 | 功能测试 | 1. 运单YB202607130001第二次上报正在自动重试中；2. 使用super_admin登录管理端 | 1. 进入第二次上报列表；2. 在自动重试进行中找到该运单；3. 尝试点击"手动上传"按钮或直接调用上报API | 运单号: YB202607130001(自动重试进行中) | 前端"手动上传"按钮不可见或被置灰（仅"上传失败"状态可见）；若通过API直接调用，返回"上报处理中"错误（分布式锁检测）；同一运单第二次上报仅产生1条有效记录；数据库unique约束（运单号+stage=2）防止重复插入 | [AI修正: 历史缺陷防御] - BUG-202607-02 |
+| AH_REPORT_R2_026 | 平台端-监管上报-第二次上报 | 验证轨迹核验异常运单的补传轨迹功能—补传后重新核验通过 | P1 | 功能测试 | 1. 运单YB202607130038第二次上报轨迹核验异常（轨迹点仅1个）；2. 运营人员准备补充的GPS轨迹数据（200个点） | 1. 进入第二次上报列表，找到轨迹异常运单；2. 点击操作列"补传轨迹"按钮；3. 上传补充的200个轨迹点数据文件；4. 提交补传；5. 等待重新核验结果 | 运单号: YB202607130038; 原始轨迹点: 1; 补传轨迹点: 200 | 仅轨迹核验异常的运单显示"补传轨迹"按钮；补传提交后系统重新触发轨迹核验；核验通过后异常项"车辆轨迹合规核验"消除，核验状态变为"通过"；补传操作在上报日志中独立记录；补传的200个轨迹点数据覆盖原有的1个点数据 | 对应TP-C-022 |
+| AH_REPORT_R2_027 | 平台端-监管上报-第二次上报 | 验证第二次上报失败后自动重试机制—最多3次、间隔递增、全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130060触发第二次上报；2. 模拟监管平台接口超时（不返回/30s超时） | 1. 触发第二次上报（超时失败）；2. 等待系统自动重试；3. 查看上报日志中每次重试的记录；4. 模拟连续3次重试均失败；5. 查看告警通知 | 运单号: YB202607130060; 重试间隔: 5s/15s/30s(参考值) | 上报失败后系统自动触发第1次重试（约5s后）；第1次失败→第2次重试（约15s后）；第2次失败→第3次重试（约30s后）；每次重试在上报日志中独立记录（共4条: 1次原始+3次重试）；3次全部失败后系统通过站内信或短信告警通知运营人员；上报状态变更为"上传失败"（红色标签），"手动上传"按钮可见可用；重试期间手动上传按钮不可用或置灰显示"上报处理中" | [AI修正: 历史缺陷防御] - BUG-202607-02；对应TP-C-023 |
+| AH_REPORT_R2_028 | 平台端-监管上报-第二次上报 | 验证第二次上报详情弹窗资金流水10字段与车辆轨迹6字段分组完整展示 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第二次上报已完成且含完整资金流水和车辆轨迹数据 | 1. 进入第二次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"资金流水信息"分组的字段；4. 查看"车辆轨迹信息"分组的字段 | 运单号: YB202607130001; 资金流水: 含完整支付信息; 车辆轨迹: 含150个点位 | 资金流水信息分组完整展示10字段: 支付金额/支付方式/支付时间/付款方名称/收款方名称/收款人/收款账号/收款账号类型/流水号/支付状态；车辆轨迹信息分组完整展示6字段: 定位类型/定位时间/定位地点/经度/纬度/轨迹类型；轨迹列表支持分页浏览（150个点分页展示）；可选字段缺失时显示"-"或"无"而不展示空白；弹窗分组标签和顺序正确: 运单信息→托运方信息→收货方信息→资金流水信息→车辆轨迹信息→异常信息 | 对应TP-C-024；[AI修正: 覆盖缺口补充] |
+
+| AH_REPORT_R2_029 | 平台端-监管上报-第二次上报 | 验证里程申诉功能—提交里程申诉接口正常 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130058存在里程数据异常（如实际里程与上报里程偏差>20%） | 1. 进入第二次上报详情页；2. 点击"里程申诉"按钮；3. 填写申诉内容"GPS里程与实际里程偏差"、投诉编号"CMP202607130001"、申诉里程"350"；4. 提交 | 运单号: YB202607130058; 申诉里程: 350km; 投诉编号: CMP202607130001 | 里程申诉提交成功，接口POST /mileageAppeal/insert返回成功响应；申诉记录中新增里程申诉记录；申诉内容、投诉编号、申诉里程字段均正确保存；缺少必选参数时接口返回明确错误提示（如"运单号不能为空"）；里程申诉与异常项申诉独立管理互不干扰 | 对应TP-C-025；[技术方案] API新增接口 |
+| AH_REPORT_R2_030 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130059委托合同编号DLC202607001有效且存在于合同管理系统；2. 委托合同有效期2026-01-01~2026-12-31覆盖运单执行日期2026-07-10~2026-07-13；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待监管平台返回核验结果；3. 查看核验状态和异常项 | 运单号: YB202607130059; 委托合同: DLC202607001(有效) | 核验状态为"通过"；无"委托合同核验"（代码100）异常项；abnormalDetails中不存在id=100的记录 | 对应TP-C-026；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_031 | 平台端-监管上报-第二次上报 | 验证委托合同核验(100)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130060委托合同编号INVALID_DLC999不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果返回；3. 查看异常项详情 | 运单号: YB202607130060; 委托合同: INVALID_DLC999(不存在) | 核验状态变为"异常"；异常项标注"委托合同核验"（代码100）；异常原因包含"委托合同不存在"或"委托合同已过期"；可发起申诉 | 对应TP-C-027；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_032 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同有效且覆盖运单日期时核验通过 | P1 | 功能测试 | 1. 运单YB202607130061承运合同编号CTC202607001有效且存在于合同管理系统；2. 承运合同有效期2026-01-01~2026-12-31覆盖运单执行日期；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130061; 承运合同: CTC202607001(有效) | 核验状态为"通过"；无"承运合同核验"（代码120）异常项；abnormalDetails中不存在id=120的记录 | 对应TP-C-028；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_033 | 平台端-监管上报-第二次上报 | 验证承运合同核验(120)—合同不存在或过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130062承运合同编号INVALID_CTC888不存在于合同管理系统；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130062; 承运合同: INVALID_CTC888(不存在) | 核验状态变为"异常"；异常项标注"承运合同核验"（代码120）；异常原因包含"承运合同不存在"或"承运合同已过期"；可发起申诉 | 对应TP-C-029；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_034 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运单执行期间有完整实时定位数据时核验通过 | P1 | 功能测试 | 1. 运单YB202607130063在运输期间（2026-07-10 08:00~2026-07-13 18:00）有持续完整的GPS实时定位数据；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130063; 定位时间范围: 完整覆盖运输期间 | 核验状态为"通过"；无"实时定位核验"（代码130）异常项 | 对应TP-C-030；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_035 | 平台端-监管上报-第二次上报 | 验证实时定位核验(130)—运输期间定位数据长时间中断时核验异常 | P1 | 功能测试 | 1. 运单YB202607130064运输期间（2026-07-10~2026-07-13）GPS定位数据在2026-07-11~2026-07-12期间中断超过24小时；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130064; 定位中断: 2026-07-11~2026-07-12(约24小时) | 核验状态变为"异常"；异常项标注"实时定位核验"（代码130）；异常原因包含"实时定位数据长时间中断"；可发起申诉或补充定位数据 | 对应TP-C-031；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_036 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—各时间节点逻辑合理时核验通过 | P1 | 功能测试 | 1. 运单YB202607130065时间节点合理：建单2026-07-09→接单2026-07-10 08:00→起运2026-07-10 10:00→送达2026-07-13 16:00；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130065; 时间序列: 建单→接单→起运→送达(合理) | 核验状态为"通过"；无"运单时间逻辑核验"（代码140）异常项 | 对应TP-C-032；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_037 | 平台端-监管上报-第二次上报 | 验证运单时间逻辑核验(140)—送达时间早于起运时间时核验异常 | P1 | 功能测试 | 1. 运单YB202607130066时间节点矛盾：起运2026-07-13 10:00→送达2026-07-12 16:00（送达早于起运）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130066; 时间倒置: 送达(07-12)早于起运(07-13) | 核验状态变为"异常"；异常项标注"运单时间逻辑核验"（代码140）；异常原因包含"送达时间早于起运时间"；可发起申诉 | 对应TP-C-033；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_038 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—有效期和证号均有效时核验通过 | P1 | 功能测试 | 1. 运单YB202607130067车辆道路运输证号RTC202501001有效，有效期2025-03-01~2027-03-01（当前日期2026-07-13在有效期内）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130067; 道路运输证号: RTC202501001(有效) | 核验状态为"通过"；无"道路运输证核验"（代码160）异常项 | 对应TP-C-034；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_039 | 平台端-监管上报-第二次上报 | 验证道路运输证核验(160)—证号在运政系统查询不存在时核验异常 | P1 | 功能测试 | 1. 运单YB202607130068车辆道路运输证号INVALID_RTC999在运政系统中查询不存在；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130068; 道路运输证号: INVALID_RTC999(不存在) | 核验状态变为"异常"；异常项标注"道路运输证核验"（代码160）；异常原因包含"道路运输证不存在"；可发起申诉 | 对应TP-C-035；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_040 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证有效且准驾车型匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130069司机驾驶证号DL202501001有效，有效期2024-01-01~2030-01-01，准驾车型B2（与重型货车匹配）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130069; 驾驶证号: DL202501001(有效); 准驾车型: B2(匹配) | 核验状态为"通过"；无"驾驶证核验"（代码170）异常项 | 对应TP-C-036；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_041 | 平台端-监管上报-第二次上报 | 验证驾驶证核验(170)—驾驶证已过期时核验异常 | P1 | 功能测试 | 1. 运单YB202607130070司机驾驶证有效期至2025-12-31（当前日期2026-07-13已过期）；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130070; 驾驶证有效期至: 2025-12-31(已过期) | 核验状态变为"异常"；异常项标注"驾驶证核验"（代码170）；异常原因包含"驾驶证已过期"；可发起申诉 | 对应TP-C-037；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_042 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—车辆无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130071车辆云A12345在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130071; 车辆: 云A12345(无时间重叠) | 核验状态为"通过"；无"车辆重复核验"（代码190）异常项 | 对应TP-C-038；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_043 | 平台端-监管上报-第二次上报 | 验证车辆重复核验(190)—同一车辆同时用于两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 车辆云A12345同时出现在运单YB202607130072（执行时段2026-07-10~2026-07-13）和运单YB202607130073（执行时段2026-07-11~2026-07-14）中，时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130072(07-10~07-13); 运单B: YB202607130073(07-11~07-14); 重叠: 07-11~07-13 | 至少一个运单核验状态变为"异常"；异常项标注"车辆重复核验"（代码190）；异常原因包含"车辆在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-039；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_044 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—司机无时间重叠运单时核验通过 | P1 | 功能测试 | 1. 运单YB202607130074司机张三(身份证510101199001011234)在运单执行时段2026-07-10~2026-07-13内无其他运单；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130074; 司机: 张三(无时间重叠) | 核验状态为"通过"；无"司机重复核验"（代码200）异常项 | 对应TP-C-040；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_045 | 平台端-监管上报-第二次上报 | 验证司机重复核验(200)—同一司机同时执行两个时间重叠运单时核验异常 | P1 | 功能测试 | 1. 司机张三同时被分配给运单YB202607130075（执行时段2026-07-10~2026-07-13）和运单YB202607130076（执行时段2026-07-12~2026-07-15），时间重叠2天；2. 第一次上报已完成 | 1. 分别触发两个运单的第二次上报；2. 查看核验结果 | 运单A: YB202607130075(07-10~07-13); 运单B: YB202607130076(07-12~07-15); 司机: 张三(重叠) | 至少一个运单核验状态变为"异常"；异常项标注"司机重复核验"（代码200）；异常原因包含"司机在运单执行期间存在时间重叠"；可发起申诉 | 对应TP-C-041；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_046 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机一致且金额匹配时核验通过 | P1 | 功能测试 | 1. 运单YB202607130077收款人张三与司机张三一致（身份证号510101199001011234匹配）；2. 收款金额¥10,000.00与运单运费一致；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130077; 收款人: 张三(与司机一致); 收款金额: ¥10,000.00 | 核验状态为"通过"；无"运费收款核验"（代码220）异常项 | 对应TP-C-042；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_047 | 平台端-监管上报-第二次上报 | 验证运费收款核验(220)—收款人与司机身份证号不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130078司机为张三(身份证510101199001011234)，但收款人为李四(身份证510101199002022345)，两者不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130078; 司机: 张三; 收款人: 李四(不一致) | 核验状态变为"异常"；异常项标注"运费收款核验"（代码220）；异常原因包含"收款人与司机信息不一致"；可发起申诉 | 对应TP-C-043；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_048 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司信息与托运方一致时核验通过 | P1 | 功能测试 | 1. 运单YB202607130079收款公司为"安徽XX物流有限公司"(统一社会信用代码9134XXXXXXXXXXXXXX)，与托运方信息完全一致；2. 收款账户已在系统中备案；3. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130079; 收款公司: 安徽XX物流有限公司(与托运方一致) | 核验状态为"通过"；无"公司统一收款核验"（代码230）异常项 | 对应TP-C-044；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_049 | 平台端-监管上报-第二次上报 | 验证公司统一收款核验(230)—收款公司统一社会信用代码与托运方不一致时核验异常 | P1 | 功能测试 | 1. 运单YB202607130080托运方为"安徽XX物流有限公司"，但收款公司为"安徽YY运输有限公司"，统一社会信用代码不一致；2. 第一次上报已完成 | 1. 触发第二次上报；2. 等待核验结果 | 运单号: YB202607130080; 托运方: 安徽XX物流; 收款公司: 安徽YY运输(不一致) | 核验状态变为"异常"；异常项标注"公司统一收款核验"（代码230）；异常原因包含"收款公司信息与托运方不一致"；可发起申诉 | 对应TP-C-045；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_050 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票号码/代码有效且信息完整时核验通过 | P1 | 功能测试 | 1. 运单YB202607130081关联的发票FP202607130081在税务系统中可查询且状态正常；2. 发票销售方和受票方信息完整；3. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 或通过API直接查询核验结果 | 运单号: YB202607130081; 发票号: FP202607130081(有效) | 核验状态为"通过"；无"发票信息核验"（代码260）异常项 | 对应TP-C-046；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_051 | 平台端-监管上报-第二次上报 | 验证发票信息核验(260)—发票已作废时核验异常 | P1 | 功能测试 | 1. 运单YB202607130082关联的发票FP202607130082在税务系统中状态为"已作废/红冲"；2. 第一次/第二次上报已完成 | 1. 触发第三次上报后等待发票核验；2. 查看核验结果 | 运单号: YB202607130082; 发票号: FP202607130082(已作废) | 核验状态变为"异常"；异常项标注"发票信息核验"（代码260）；异常原因包含"发票已作废"或"发票状态异常"；可发起申诉 | 对应TP-C-047；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_052 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆运营证照齐全且合规时核验通过 | P1 | 功能测试 | 1. 运单YB202607130083车辆运营证照齐全(道路运输证/行驶证均在有效期内)且未被标记为黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130083; 车辆证照: 齐全有效 | 核验状态为"通过"；无"非通行车辆可开票核验"（代码270）异常项 | 对应TP-C-048；[技术方案] API文档§4.1 |
+| AH_REPORT_R2_053 | 平台端-监管上报-第二次上报 | 验证非通行车辆可开票核验(270)—车辆被标记为黑名单时核验异常 | P1 | 功能测试 | 1. 运单YB202607130084车辆已被监管平台标记为运营异常/黑名单；2. 第一次/第二次上报已完成 | 1. 触发上报后等待核验；2. 查看核验结果 | 运单号: YB202607130084; 车辆状态: 黑名单 | 核验状态变为"异常"；异常项标注"非通行车辆可开票核验"（代码270）；异常原因包含"车辆不合规"或"车辆不在可开票范围"；可发起申诉 | 对应TP-C-049；[技术方案] API文档§4.1 |
+
+---
+
+## 模块D: 第三次上报-开票完成
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_R3_001 | 平台端-监管上报-第三次上报 | 验证发票开具完成后自动触发第三次上报且包含发票信息17字段 | P0 | 功能测试 | 1. 运单YB202607130001已完成第二次上报且状态为"已上传"；2. 该运单发票FP202607130001已开具完成 | 1. 系统收到发票开具完成事件；2. 进入管理端"监管上报-第三次上报"列表查看 | 运单号: YB202607130001; 发票号: FP202607130001; 发票金额(价税合计): ¥10,300.00 | 第三次上报列表中新增该运单记录，上报状态从"上传中"变为"已上传"（绿色标签）；上报请求包含运单信息+发票信息17字段+托运单号数组；若运单无关联油气发票则油气发票信息字段为空；数据库report_record表新增stage=3的记录 | 对应TP-D-001 |
+| AH_REPORT_R3_002 | 平台端-监管上报-第三次上报 | 验证第三次上报列表展示13个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 第三次上报列表中有至少1条已完成的记录 | 1. 进入"监管上报-第三次上报"列表；2. 查看列表表头和第一条数据的所有列内容 | 运单号: YB202607130001; 发票号: FP202607130001 | 列表展示13个字段: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作；发票金额保留2位小数；开票日期格式为YYYY-MM-DD；核验状态标签颜色符合规范 | 对应TP-D-002；⚠️ 待确认: 原型列表比需求多4个字段（税率/销售方名称/受票方名称/油气票张数），共15列 |
+| AH_REPORT_R3_003 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗发票信息19字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001第三次上报已完成 | 1. 进入第三次上报列表；2. 点击运单YB202607130001的"详情"按钮；3. 查看"发票信息"分组的所有字段 | 运单号: YB202607130001; 发票号: FP202607130001; 发票代码: 1234567890; 价税合计: ¥10,300.00 | 发票信息分组展示19字段: 托运单号数组（支持多个托运单号）、发票号码、发票代码号、发票金额(价税合计)、开票日期（必选字段完整）；销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）完整；受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）完整；注：第三次上报无税率字段 | 对应TP-D-003 |
+| AH_REPORT_R3_004 | 平台端-监管上报-第三次上报 | 验证运单关联油气发票时第三次上报包含油气发票信息 | P2 | 功能测试 | 1. 运单YB202607130040关联油气发票YQFP202607001；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票信息字段；3. 查看详情弹窗 | 运单号: YB202607130040; 油气发票: YQFP202607001 | 上报请求JSON包含油气发票信息（油气托运单号、油气发票文件）；详情弹窗中油气发票信息正确展示；油气发票文件支持查看和下载 | 对应TP-D-004 |
+| AH_REPORT_R3_005 | 平台端-监管上报-第三次上报 | 验证无油气发票时第三次上报正常完成（可选字段为空） | P2 | 功能测试 | 1. 运单YB202607130001无关联油气发票；2. 该运单发票开具完成 | 1. 触发第三次上报；2. 查看上报请求JSON中油气发票相关字段 | 运单号: YB202607130001; 油气发票: 无 | 上报请求JSON中油气发票字段为null或不传；上报成功，不报错；详情弹窗中油气发票区域显示"-"或"无" | 对应TP-D-004 |
+| AH_REPORT_R3_006 | 平台端-监管上报-第三次上报 | 验证第三次上报依赖第二次上报完成—第二次上报失败时第三次上报被拒绝 | P0 | 功能测试 | 1. 运单YB202607130041第二次上报状态为"上传失败"；2. 该运单发票已开具完成 | 1. 发票开具完成事件触发第三次上报；2. 查看第三次上报接口返回 | 运单号: YB202607130041(第二次上报失败) | 接口返回错误，错误码明确标识"前置上报（第二次）未完成"；后端通过查询report_status表校验第二阶段的完成状态；第三次上报列表无该运单记录 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_R3_007 | 平台端-监管上报-第三次上报 | 验证第三次上报完整依赖链校验—第1失败→第2无法完成→第3被拒绝 | P0 | 功能测试 | 1. 运单YB202607130042第一次上报状态为"上传失败" | 1. 通过API依次尝试调用第二次上报接口和第三次上报接口；2. 查看每个接口的返回 | 运单号: YB202607130042 | 第一次上报失败→第二次上报接口返回"前置上报未完成"；第二次上报无法完成→第三次上报接口同样返回"前置上报未完成"（含第二次）；三阶段依赖链校验在后端完整实现，不可跳级 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_R3_008 | 平台端-监管上报-第三次上报 | 验证增值税发票号码格式无效时第三次上报失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130043发票号码格式无效（如"ABC"非标准格式）；2. 第二次上报已完成 | 1. 触发第三次上报；2. 查看上报接口返回的错误信息 | 运单号: YB202607130043; 发票号码: ABC(无效格式) | 接口返回校验错误，提示"发票号码格式无效"或类似消息；上报状态标记为"上传失败"（红色标签）；错误信息明确指出具体错误字段为发票号码；数据库无该运单第三次上报的成功记录 | 对应TP-D-006 |
+| AH_REPORT_R3_009 | 平台端-监管上报-第三次上报 | 验证发票代码与发票号码不匹配时第三次上报失败 | P1 | 功能测试 | 1. 运单YB202607130044发票代码1234567890与发票号码FP202607130001不匹配 | 1. 触发第三次上报；2. 查看接口返回 | 运单号: YB202607130044; 不匹配的发票代码/号码 | 接口返回校验错误，提示"发票代码与发票号码不匹配"；上报状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-D-006 |
+| AH_REPORT_R3_010 | 平台端-监管上报-第三次上报 | 验证第三次上报失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130045第三次上报时模拟监管平台持续返回失败 | 1. 触发第三次上报；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警通知 | 运单号: YB202607130045; 发票号: FP202607130045 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后上报状态标记为"上传失败"（红色）并停止重试；super_admin收到告警通知，内容包含运单号YB202607130045、发票号FP202607130045、失败原因 | 对应TP-D-007 |
+| AH_REPORT_R3_011 | 平台端-监管上报-第三次上报 | 验证第三次上报幂等性—同一运单同一发票信息不能重复上报 | P1 | 功能测试 | 1. 运单YB202607130001第三次上报已成功（发票FP202607130001）；2. 尝试再次触发第三次上报 | 1. 通过API再次调用第三次上报接口（同一运单+同一发票）；2. 查看接口返回 | 运单号: YB202607130001; 发票号: FP202607130001(已上报) | 接口返回"上报已存在"或"该发票已上报"提示；数据库report_record表不会新增重复记录（唯一约束：运单号+stage=3+发票号）；分布式锁或幂等键控制并发 | 对应TP-D-009 |
+| AH_REPORT_R3_012 | 平台端-监管上报-第三次上报 | 验证第三次上报发票金额精度—价税合计保留2位小数无浮点数精度问题 | P1 | 功能测试 | 1. 准备发票金额为¥0.01、¥9,999.99、¥999,999.99的三张发票 | 1. 分别对三张发票触发第三次上报；2. 查看上报请求JSON中的金额字段；3. 对比数据库发票表和上报记录中的金额 | 金额1: ¥0.01; 金额2: ¥9,999.99; 金额3: ¥999,999.99 | 三个金额均保留2位小数并精确传输（如0.01不为0.009999...）；大金额¥999,999.99不出现溢出或截断；数据库金额字段使用DECIMAL类型非FLOAT；上报数据与开票系统数据完全一致 | 对应TP-D-010 |
+| AH_REPORT_R3_013 | 平台端-监管上报-第三次上报 | 验证第三次上报运单信息数据来源—价格和货物信息来源于运单表实时数据 | P2 | 功能测试 | 1. 运单YB202607130046装货完成时货物信息含"钢材10吨"；2. 在第三次上报前修改运单表货物信息为"钢材12吨" | 1. 修改运单表的货物信息；2. 触发第三次上报；3. 查看上报请求中的货物信息数据 | 运单号: YB202607130046; 原货物量: 10吨; 修改后: 12吨 | 上报请求中的货物信息为"钢材12吨"（最新值），非"钢材10吨"（装货时快照）；数据来源为运单表实时查询；不依赖装货完成时的数据缓存 | 对应TP-D-011 |
+| AH_REPORT_R3_014 | 平台端-监管上报-第三次上报 | 验证第三次上报详情弹窗异常信息分组与申诉模块数据联动 | P2 | 功能测试 | 1. 运单YB202607130046第三次上报核验异常；2. 已对该运单发起申诉且申诉状态为"申诉中" | 1. 进入第三次上报列表；2. 点击运单YB202607130046的"详情"按钮；3. 查看"异常信息"分组 | 运单号: YB202607130046; 申诉状态: 申诉中 | 异常信息分组包含核验状态（异常）、异常原因（具体异常项）、异常时间（核验时间）、处理状态（申诉中）；处理状态与申诉模块数据一致（联动）；申诉状态变更后详情弹窗中处理状态同步更新 | 对应TP-D-008 |
+| AH_REPORT_R3_015 | 平台端-监管上报-第三次上报 | 验证发票合规查询接口—查询托运人发票是否通过系统核验合规 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 托运人"安徽XX物流有限公司"存在已核验合规的发票记录 | 1. 调用POST /verificationSummary/cargoOwnerInvoiceInfo接口；2. 传入托运人识别信息（统一社会信用代码/名称）；3. 查看返回的发票合规状态 | 托运人: 安徽XX物流有限公司; 统一社会信用代码: 9134XXXXXXXXXXXXXX | 接口返回发票合规状态为"合规/通过"；若发票不合规则返回异常原因和具体不合规项；接口支持批量查询多个托运人发票合规状态；响应时间<3s；传入无效托运人信息时返回明确错误提示 | 对应TP-D-012；[技术方案] API新增接口 |
+
+---
+
+## 模块E: ETC发票上传
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_ETC_001 | 平台端-监管上报-ETC上传 | 验证税务抵扣完成后ETC发票上传成功且列表数据正确 | P0 | 功能测试 | 1. 运单YB202607130001的ETC发票ETC202607130001税务抵扣已完成；2. ETC发票信息18字段完整 | 1. 触发ETC发票上传（自动或手动）；2. 进入管理端"监管上报-ETC上传"列表查看；3. 查看上传请求JSON内容 | 运单号: YB202607130001; ETC发票号: ETC202607130001; 发票金额: ¥100.00; 税率: 3% | ETC上传列表中出现该记录，上传状态为"已上传"（绿色标签）；上报请求JSON包含运单信息7字段+ETC发票信息18字段；数据库etc_report_record表新增记录，status=1 | 对应TP-E-001 |
+| AH_REPORT_ETC_002 | 平台端-监管上报-ETC上传 | 验证ETC上传列表展示11个字段完整且数据正确 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有至少1条记录 | 1. 进入"监管上报-ETC上传"列表；2. 查看列表表头和第一条数据的所有列 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 列表展示: 货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/ETC发票号码/发票金额/税率/上传状态/操作；发票金额正确展示，税率显示3%；上传状态标签颜色符合规范 | 对应TP-E-002 |
+| AH_REPORT_ETC_003 | 平台端-监管上报-ETC上传 | 验证ETC发票详情弹窗3个分组字段完整（运单信息/ETC发票信息18字段/异常信息） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. ETC上传列表中有已完成上传的记录 | 1. 进入ETC上传列表；2. 点击运单YB202607130001操作列的"详情"按钮；3. 依次查看各分组字段 | 运单号: YB202607130001; ETC发票号: ETC202607130001 | 运单信息分组7字段完整；ETC发票信息分组18字段完整展示: ETC发票号码、ETC发票代码、开票时间、发票金额、税率(3%)、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件；异常信息分组4字段（核验状态/异常原因/异常时间/处理状态） | 对应TP-E-003 |
+| AH_REPORT_ETC_004 | 平台端-监管上报-ETC上传 | 验证税务抵扣未完成时ETC上传被拒绝并提示"请先完成税务抵扣" | P0 | 功能测试 | 1. 运单YB202607130047的ETC发票税务抵扣状态为"未完成" | 1. 尝试触发ETC发票上传（调用API或页面操作）；2. 查看接口返回 | 运单号: YB202607130047; 税务抵扣: 未完成 | 上传接口返回错误，提示"请先完成税务抵扣"；后端校验税务抵扣状态为已完成才允许上传；ETC上传列表中不会出现该运单记录 | 对应TP-E-004 |
+| AH_REPORT_ETC_005 | 平台端-监管上报-ETC上传 | 验证ETC发票号码格式无效时上传失败并明确提示 | P1 | 功能测试 | 1. 运单YB202607130048关联的ETC发票号码格式无效（如"ETC-ABC"不符合规定格式） | 1. 税务抵扣完成后触发上传；2. 查看接口返回 | 运单号: YB202607130048; ETC发票号码: ETC-ABC(无效) | 上传接口返回校验错误，提示"ETC发票号码格式无效"；上传状态标记为"上传失败"；错误提示指明具体错误字段 | 对应TP-E-005 |
+| AH_REPORT_ETC_006 | 平台端-监管上报-ETC上传 | 验证ETC发票税率非3%时上传失败并提示税率异常 | P1 | 功能测试 | 1. 运单YB202607130049关联的ETC发票税率字段为5%（非标准3%） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130049; ETC发票税率: 5%(非标准) | 上传接口返回校验错误，提示"税率异常（应为3%）"；上传状态标记为"上传失败"；不会将错误税率数据上报至监管平台 | 对应TP-E-005 |
+| AH_REPORT_ETC_007 | 平台端-监管上报-ETC上传 | 验证ETC上传失败后自动重试最多3次全部失败后告警 | P1 | 功能测试 | 1. 运单YB202607130050 ETC上传时模拟监管平台持续返回失败 | 1. 触发ETC上传；2. 监控上报日志中的重试记录；3. 等待3次重试全部完成后查看告警 | 运单号: YB202607130050; ETC发票号: ETC202607130050 | 自动重试3次（总共4次尝试）；重试间隔递增；3次重试全部失败后标记"上传失败"（红色标签）并停止重试；super_admin收到告警通知；每次重试均记录到上报日志 | 对应TP-E-006 |
+| AH_REPORT_ETC_008 | 平台端-监管上报-ETC上传 | 验证ETC税额计算公式—税额=发票金额×3%结果保留2位小数 | P1 | 功能测试 | 1. 准备3张ETC发票：金额¥100.00、¥0.01、¥1,000,000.00 | 1. 分别对三张发票触发上传；2. 查看上报请求JSON中的税额和价税合计字段；3. 验证计算逻辑 | 发票1: ¥100.00→税额¥3.00; 发票2: ¥0.01→税额¥0.00; 发票3: ¥1,000,000.00→税额¥30,000.00 | 发票1: 税额=3.00, 价税合计=103.00, 计算正确；发票2: 税额按四舍五入规则处理（0.01×3%=0.0003→0.00）；发票3: 税额=30000.00, 大金额计算不溢出；所有税额保留2位小数 | 对应TP-E-007 |
+| AH_REPORT_ETC_009 | 平台端-监管上报-ETC上传 | 验证同一ETC发票号重复上传时被拒绝且提示"该ETC发票已上传" | P1 | 功能测试 | 1. ETC发票ETC202607130001已成功上传 | 1. 再次触发同一ETC发票的上传；2. 查看接口返回 | ETC发票号: ETC202607130001(已上传) | 接口返回"该ETC发票已上传"提示；数据库etc_report_record表不会产生重复记录（唯一约束：ETC发票号）；分布式锁/幂等键控制并发 | 对应TP-E-008 |
+| AH_REPORT_ETC_010 | 平台端-监管上报-ETC上传 | 验证同一运单关联多张ETC发票时各自独立上传且税额分别计算 | P2 | 功能测试 | 1. 运单YB202607130001关联3张ETC发票：ETC202607130001(¥100.00)、ETC202607130002(¥200.00)、ETC202607130003(¥150.00) | 1. 分别触发3张ETC发票的上传；2. 查看ETC上传列表；3. 验证每张发票的税额计算 | ETC1: ¥100.00→税¥3.00; ETC2: ¥200.00→税¥6.00; ETC3: ¥150.00→税¥4.50 | 列表中同一运单展示3条ETC上传记录；每张发票的税额独立计算正确；多张发票上传互不干扰；合计税额=¥13.50正确汇总 | 对应TP-E-009 |
+| AH_REPORT_ETC_011 | 平台端-监管上报-ETC上传 | 验证ETC发票代码与号码不匹配时上传失败 | P1 | 功能测试 | 1. 运单YB202607130051的ETC发票代码与号码不匹配（代码对应其他发票） | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130051; 不匹配的ETC发票代码/号码 | 上传接口返回校验错误，提示"ETC发票代码与号码不匹配"；上传状态标记为"上传失败"；错误信息指明具体错误字段 | 对应TP-E-005 |
+| AH_REPORT_ETC_012 | 平台端-监管上报-ETC上传 | 验证交易金额与实际通行费不匹配时ETC上传验证失败 | P1 | 功能测试 | 1. 运单YB202607130052的ETC发票中交易金额¥50.00与实际通行费¥80.00不匹配 | 1. 触发上传；2. 查看接口返回 | 运单号: YB202607130052; 交易金额: ¥50.00; 实际通行费: ¥80.00(不匹配) | 上传接口返回校验错误，提示"交易金额与实际通行费不匹配"；上传状态标记为"上传失败" | 对应TP-E-005 |
+
+---
+
+## 模块F: 异常申诉功能
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_APL_001 | 平台端-监管上报-异常申诉 | 验证申诉完整闭环—从发起申诉到申诉通过的端到端流程 | P0 | 功能测试 | 1. 运单YB202607130002第二次上报"车辆资质核验"异常；2. 使用super_admin登录管理端；3. 准备申诉附件材料（车辆道路运输证更新后的PDF） | 1. 从看板或第二次上报列表找到异常运单YB202607130002；2. 点击"申诉"按钮进入申诉页面；3. 填写申诉原因"道路运输证已续期，附新证"；4. 上传申诉附件；5. 点击"提交申诉"；6. 模拟省平台复核通过并返回反馈；7. 查看申诉状态变化 | 运单号: YB202607130002; 异常项: 车辆资质核验; 申诉原因: 道路运输证已续期; 附件: 新道路运输证.pdf | 提交申诉后申诉状态变为"申诉中"；省平台复核通过后状态变为"申诉通过"（绿色标签）；申诉记录页面中该申诉记录状态为"申诉通过"；处理记录时间线中每条操作均有记录；原异常运单核验状态可能根据省平台反馈更新 | 对应TP-F-001；⚠️ 待确认: 申诉状态枚举三版本不一致——需求(未申诉/申诉中/申诉通过/申诉驳回)、原型(未申诉/待省平台反馈/反馈处理中/申诉通过/申诉驳回)、API(未申诉100/审核通过110/审核不通过120/已取消130) |
+| AH_REPORT_APL_002 | 平台端-监管上报-异常申诉 | 验证申诉驳回后运营人员重新申诉补充材料再发起 | P1 | 功能测试 | 1. 运单YB202607130002申诉状态为"申诉驳回"；2. 省平台反馈意见"证明材料不充分" | 1. 进入申诉记录页面，找到驳回的申诉记录；2. 点击"重新申诉"按钮；3. 补充新的附件材料（补充证明.pdf）；4. 修改申诉原因；5. 提交 | 运单号: YB202607130002; 原申诉被驳回; 新附件: 补充证明.pdf | "重新申诉"按钮可见可用；重新申诉后生成新的申诉单号（不同于原申诉单号）；原有申诉记录保留不丢失；新申诉有独立的处理记录时间线；申诉状态变为"申诉中"重新进入复核流程 | 对应TP-F-006 |
+| AH_REPORT_APL_003 | 平台端-监管上报-异常申诉 | 验证申诉记录列表14个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 申诉记录列表中有至少1条申诉记录 | 1. 进入"监管上报-异常申诉"申诉记录页面；2. 查看列表表头和第一条数据的各列 | 申诉单含完整字段 | 列表展示14个字段: 运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作；申诉时间为实际提交时间；省平台反馈结果与实际反馈内容一致 | 对应TP-F-002 |
+| AH_REPORT_APL_004 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—未申诉→申诉中→申诉通过(终态不可变更) | P0 | 功能测试 | 1. 运单YB202607130053核验异常且申诉状态为"未申诉" | 1. 发起申诉，验证状态变为"申诉中"；2. 模拟省平台复核通过；3. 验证状态变为"申诉通过"；4. 尝试再次对该申诉记录操作（如重新申诉） | 运单号: YB202607130053 | 未申诉→申诉中（提交后立即变更）；申诉中→申诉通过（省平台反馈后变更）；申诉通过为终态，不可再变更（"重新申诉"等操作按钮不可见）；每次状态变更记录到处理记录时间线 | 对应TP-F-003；⚠️ 待确认: API申诉状态为未申诉(100)/审核通过(110)/审核不通过(120)/已取消(130)，无"申诉中"状态 |
+| AH_REPORT_APL_005 | 平台端-监管上报-异常申诉 | 验证申诉状态流转—申诉中状态下不可重复发起申诉 | P0 | 功能测试 | 1. 运单YB202607130054申诉状态为"申诉中" | 1. 尝试通过API或页面再次对该运单同一异常项发起申诉；2. 观察系统响应 | 运单号: YB202607130054; 申诉状态: 申诉中 | 页面"申诉"按钮被禁用或点击后提示"申诉处理中，请勿重复提交"；后端API返回错误，提示"该异常项已有申诉在处理中"；数据库不会产生重复申诉记录 | 对应TP-F-003; TP-F-012 |
+| AH_REPORT_APL_006 | 平台端-监管上报-异常申诉 | 验证申诉详情弹窗5个分组字段完整（申诉信息/运单信息/异常信息/省平台反馈/处理记录） | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在一条已完成的申诉记录 | 1. 进入申诉记录页面；2. 点击某条记录的"详情"按钮；3. 依次查看5个分组的内容 | 申诉单号: APL202607130001 | 申诉信息分组含: 申诉单号/上报阶段/异常项/申诉原因/申诉状态/申诉时间/申诉人/申诉附件；省平台反馈信息含: 反馈结果/反馈时间/反馈意见；处理记录以时间线形式倒序展示：操作人/操作时间/操作类型/操作内容，每步操作（发起申诉/省平台反馈/重新申诉）均有一条记录 | 对应TP-F-004 |
+| AH_REPORT_APL_007 | 平台端-监管上报-异常申诉 | 验证申诉附件上传—支持多附件且格式校验正确 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 准备png、jpg、pdf格式的附件文件各1个，以及1个超出大小限制的文件(如10MB) | 1. 进入申诉发起页面；2. 依次上传png/jpg/pdf文件；3. 尝试上传超限文件 | 附件: 证明1.png(500KB), 证明2.jpg(800KB), 证明3.pdf(1.5MB), 超限文件.exe(10MB) | png/jpg/pdf格式上传成功，附件列表展示文件名和大小；超限文件上传时提示"文件大小超过限制"；上传失败有重试机制；申诉详情弹窗中可查看/下载已上传的附件 | 对应TP-F-005 |
+| AH_REPORT_APL_008 | 平台端-监管上报-异常申诉 | 验证7类核验异常（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹）各自独立发起申诉 | P1 | 功能测试 | 1. 准备7条运单，每条分别对应一种核验异常 | 1. 分别对7条运单发起申诉；2. 查看每条申诉记录中的异常项信息；3. 验证各申诉独立互不干扰 | 运单A: 运单重复异常; B: 车辆资质异常; C: 司机资质异常; D: 集中支付异常; E: 资金流水异常; F: 合同异常; G: 轨迹合规异常 | 7条申诉各自独立创建，异常项信息与核验结果一致；每条申诉的异常项字段正确标注对应的核验类别；某一异常项申诉不影响其他异常项的申诉状态 | 对应TP-F-007；⚠️ 待确认: 核验项从需求7类扩展为API文档17项，每项是否均有独立申诉入口待确认 |
+| AH_REPORT_APL_009 | 平台端-监管上报-异常申诉 | 验证从看板操作列点击申诉按钮跳转至申诉页面并自动填充运单号 | P1 | 功能测试 | 1. 看板中存在核验异常的运单YB202607130002；2. 使用super_admin登录管理端 | 1. 进入看板页面；2. 在异常运单YB202607130002的操作列点击"申诉"按钮；3. 观察页面跳转和预填充数据 | 运单号: YB202607130002 | 页面路由正确跳转至申诉发起页面；URL携带正确的运单ID参数；申诉页面自动加载该运单的异常信息（运单号YB202607130002、异常项预填充正确）；运营人员无需手动输入运单号 | 对应TP-F-008 |
+| AH_REPORT_APL_010 | 平台端-监管上报-异常申诉 | 验证仅运营人员有权发起申诉—司机/车队长/财务无申诉操作权限 | P1 | 安全性测试 | 1. 准备运营(super_admin)、财务、车队长(13113113113)、司机(15188888888)账号 | 1. 用各账号分别登录；2. 访问申诉功能页面；3. 尝试通过API直接调用申诉接口 | 运营: super_admin; 财务: finance_user; 车队长: 13113113113; 司机: 15188888888 | 运营人员可见"申诉"按钮和申诉记录页面，可发起申诉；车队长/司机端无申诉功能入口，直接URL访问返回403；财务人员可查看申诉记录但"发起申诉"按钮不可见；越权操作被拦截并记录审计日志（操作人/操作时间/操作内容/拦截原因） | 对应TP-F-009 |
+| AH_REPORT_APL_011 | 平台端-监管上报-异常申诉 | 验证申诉处理记录时间线按时间倒序排列且操作时间精确到秒 | P2 | 功能测试 | 1. 存在一条经历了发起申诉→省平台反馈→重新申诉→省平台再次反馈的完整申诉记录 | 1. 进入申诉详情弹窗；2. 查看"处理记录"时间线 | 申诉单号: APL202607130002 | 4条操作记录按时间倒序排列（最新的在最上面）；每条记录包含: 操作人（用户名或"省平台"）、操作时间（YYYY-MM-DD HH:mm:ss）、操作类型（发起申诉/复核通过/复核驳回/重新申诉）、操作内容描述；操作类型与实际情况准确对应 | 对应TP-F-010 |
+| AH_REPORT_APL_012 | 平台端-监管上报-异常申诉 | 验证异常代码一览表映射—已知异常代码正确映射为中文异常项名称 | P2 | 功能测试 | 1. 模拟省平台返回已知异常代码（如"VEHICLE_QUAL_FAIL"） | 1. 查看申诉页面中该异常代码对应的中文展示；2. 验证映射关系正确 | 异常代码: VEHICLE_QUAL_FAIL | 申诉页面中异常项显示为"车辆资质核验"（中文），非原始代码"VEHICLE_QUAL_FAIL"；异常代码与中文名称一一对应无歧义 | 对应TP-F-011 |
+| AH_REPORT_APL_013 | 平台端-监管上报-异常申诉 | 验证未知异常代码兜底展示—显示原始代码+标注未知异常 | P2 | 功能测试 | 1. 模拟省平台返回一个系统中未定义的异常代码（如"UNKNOWN_ERROR_999"） | 1. 查看申诉页面异常项的展示 | 未知异常代码: UNKNOWN_ERROR_999 | 申诉页面中异常项显示原始代码"UNKNOWN_ERROR_999"并标注"(未知异常)"或类似兜底文案（不崩溃、不显示乱码）；系统日志中记录"未识别的异常代码"便于后续排查 | 对应TP-F-011 |
+| AH_REPORT_APL_014 | 平台端-监管上报-异常申诉 | 验证同一异常项申诉中状态下快速双击提交申诉仅产生1条记录 | P2 | 功能测试 | 1. 运单YB202607130055核验异常，申诉状态为"未申诉" | 1. 进入申诉页面填写完整信息；2. 快速双击"提交申诉"按钮；3. 查看申诉记录列表 | 运单号: YB202607130055; 异常项: 资金流水核验 | 申诉记录列表中仅产生1条申诉记录（前端防抖+后端校验）；后端有状态校验，"申诉中"状态下不可重新发起；数据库appeal_record表该运单+该异常项仅有1条"申诉中"记录 | 对应TP-F-012 |
+| AH_REPORT_APL_015 | 平台端-监管上报-异常申诉 | 验证申诉提交后省平台长时间无反馈(超7个工作日)时系统有合理状态提示 | P3 | 功能测试 | 1. 运单YB202607130056申诉状态为"申诉中"；2. 模拟时间超过7个工作日省平台无反馈 | 1. 进入申诉记录页面查看该申诉记录；2. 查看系统是否有超时提示或告警 | 运单号: YB202607130056; 等待时长: 超过7个工作日 | 申诉记录页面显示"等待省平台复核中"或类似状态提示（申诉状态仍为"申诉中"不自动变更）；运营人员可查看申诉等待时长（如"已等待8个工作日"）；系统应触发超时告警通知运营人员跟进（告警渠道和阈值待确认）；不自动变更申诉状态为通过或驳回 | 对应TP-F-013；> ⚠️ 待确认：申诉超时告警机制（告警渠道、触发阈值）需与产品确认 |
+| AH_REPORT_APL_016 | 平台端-监管上报-异常申诉 | 验证申诉附件上传失败时有重试机制 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 模拟附件上传接口服务暂时不可用 | 1. 进入申诉发起页面；2. 填写申诉信息并选择附件上传；3. 在上传过程中模拟服务异常 | 附件: 证明文件.png(500KB) | 附件上传失败时前端显示"上传失败，点击重试"提示；点击重试后可重新上传；上传成功后可正常提交申诉；失败不影响已填写的申诉文字内容 | 对应TP-F-005 |
+| AH_REPORT_APL_017 | 平台端-监管上报-异常申诉 | 验证财务人员可查看申诉记录但不可发起申诉 | P1 | 安全性测试 | 1. 使用财务账号登录管理端；2. 申诉记录中有数据 | 1. 进入申诉记录页面，查看是否有"发起申诉"按钮；2. 查看申诉详情是否可读；3. 尝试通过API调用申诉发起接口 | 财务账号: finance_user | 申诉记录列表正常展示，可查看详情；"发起申诉"按钮不可见（或置灰）；通过API直接调用申诉发起接口返回403 Forbidden；审计日志中记录财务账号的查看操作 | 对应TP-F-009 |
+
+---
+
+## 模块G: 上报日志
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_LOG_001 | 平台端-监管上报-上报日志 | 验证上报日志按完整运单号精确搜索日志记录 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001存在上报日志记录 | 1. 进入"监管上报-上报日志"页面；2. 在运单号搜索框输入"YB202607130001"；3. 点击搜索 | 运单号: YB202607130001 | 列表仅展示与该运单号相关的所有上报日志记录（含各阶段的重试记录）；数据库查询结果与页面展示一致 | 对应TP-G-001 |
+| AH_REPORT_LOG_002 | 平台端-监管上报-上报日志 | 验证上报日志按不存在的单号搜索显示空结果 | P1 | 功能测试 | 1. 使用super_admin登录管理端 | 1. 进入"监管上报-上报日志"页面；2. 输入不存在的单号"NOTEXIST999"；3. 点击搜索 | 运单号: NOTEXIST999 | 列表显示空结果，友好提示"未找到相关日志记录"；控制台无报错 | 对应TP-G-001 |
+| AH_REPORT_LOG_003 | 平台端-监管上报-上报日志 | 验证上报日志按"第一次上报"阶段筛选日志 | P0 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中同时存在第一次上报和第二次上报的记录 | 1. 进入"监管上报-上报日志"页面；2. 选择上报阶段"第一次上报"；3. 查看筛选结果 | 筛选条件: 第一次上报 | 列表仅展示stage=1的日志记录；ETC上传日志不包含在内；切换至"ETC上传"时有独立筛选项，日志正确过滤 | 对应TP-G-002 |
+| AH_REPORT_LOG_004 | 平台端-监管上报-上报日志 | 验证上报日志按"失败"结果筛选—展示所有非成功日志 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在成功(HTTP 200)和失败(HTTP 4xx/5xx/超时)的记录 | 1. 进入日志页面；2. 选择上报结果"失败"；3. 查看筛选结果 | 筛选: 失败 | 列表展示所有非2xx的日志记录，包括HTTP 400/500/超时等；"成功"(200)的记录被过滤；筛选结果与实际日志记录一致 | 对应TP-G-003 |
+| AH_REPORT_LOG_005 | 平台端-监管上报-上报日志 | 验证上报日志按时间范围筛选（跨天） | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中存在2026-07-10至2026-07-13的记录 | 1. 进入日志页面；2. 选择开始时间"2026-07-10 00:00:00"，结束时间"2026-07-12 23:59:59"；3. 点击搜索 | 时间范围: 2026-07-10~2026-07-12 | 列表仅展示该时间范围内的日志记录；不包含2026-07-13的日志；开始时间>结束时间时系统给出提示或自动交换；不选时间范围时默认展示全部 | 对应TP-G-004 |
+| AH_REPORT_LOG_006 | 平台端-监管上报-上报日志 | 验证上报日志列表11个字段完整展示 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有至少1条完整记录 | 1. 进入日志页面；2. 查看列表表头和第一条数据的所有列 | 查看一条典型日志记录 | 列表展示: 序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作；接口URL完整（含域名和路径如https://anhui.report.gov.cn/api/v1/waybill/submit）；HTTP状态码为实际返回状态码；响应时间单位为ms；上报时间为实际请求发起时间 | 对应TP-G-005 |
+| AH_REPORT_LOG_007 | 平台端-监管上报-上报日志 | 验证点击日志操作列详情按钮弹窗展示完整请求和响应报文 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志中有1条失败记录 | 1. 进入日志页面；2. 点击某条日志操作列的"详情"按钮；3. 在弹窗中查看请求报文和响应报文 | 查看一条HTTP 400失败的日志详情 | 弹窗展示请求报文: URL（完整）、Method（POST）、Headers（Content-Type/Authorization等）、Body（完整JSON）；响应报文: Status Code（400）、Headers、Body（错误信息JSON）；JSON报文格式化展示（缩进/语法高亮）；长报文支持滚动查看；支持一键复制请求/响应内容 | 对应TP-G-006 |
+| AH_REPORT_LOG_008 | 平台端-监管上报-上报日志 | 验证每个上报阶段及自动修改字段接口的每次调用均在日志中完整记录 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 运单YB202607130001已完成全流程上报（第一次+修改字段+第二次+7核验+第三次+ETC） | 1. 进入日志页面；2. 按运单号YB202607130001搜索；3. 逐条检查日志记录是否覆盖所有阶段 | 运单号: YB202607130001 | 日志中至少包含以下记录: 第一次上报请求+响应、第一次上报修改字段请求+响应、第二次上报请求+响应、7类核验各自的请求+响应日志、第三次上报请求+响应、ETC上传请求+响应；自动重试的每次请求均独立记录（如第一次上报失败重试2次→共3条日志） | 对应TP-G-007 |
+| AH_REPORT_LOG_009 | 平台端-监管上报-上报日志 | 验证上报失败日志包含完整的Error Response Body和重试次数标记 | P1 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在上报失败的日志记录 | 1. 进入日志页面；2. 筛选"失败"的日志；3. 点击某条失败日志的详情；4. 查看失败信息完整度 | 查看一条第2次重试失败的日志 | 失败日志包含完整的Error Response Body（JSON格式）；超时日志标注"timeout"并记录超时时长（如30000ms）；重试日志中标注当前是第几次重试（如"重试第2/3次"）；异常日志可关联到具体运单ID，方便排查 | 对应TP-G-008 |
+| AH_REPORT_LOG_010 | 平台端-监管上报-上报日志 | 验证上报日志区分自动触发和手动触发—自动标注"系统自动"/手动标注操作人 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 存在自动触发的上报日志和手动触发的上报日志 | 1. 进入日志页面；2. 查看自动触发上报的日志记录中的操作人字段；3. 查看手动触发上报的日志记录中的操作人字段 | 自动日志: 第一次上报(装货完成触发); 手动日志: 第一次上报(手动上传) | 自动触发的上报日志操作人标注"系统自动"或"auto"；手动触发的上报日志操作人标注实际登录用户名（如"super_admin"）；审计日志中操作人信息与实际登录用户一致 | 对应TP-G-009 |
+| AH_REPORT_LOG_011 | 平台端-监管上报-上报日志 | 验证上报日志组合筛选—阶段+结果+时间范围+单号同时筛选 | P2 | 功能测试 | 1. 使用super_admin登录管理端；2. 日志数据满足组合条件 | 1. 进入日志页面；2. 设置: 阶段=第二次上报、结果=失败、时间范围=2026-07-10~2026-07-13、运单号=YB20260713；3. 点击搜索 | 组合: 第二次上报+失败+2026-07-10~2026-07-13+YB20260713 | 列表仅展示同时满足4个条件的日志记录；各条件在数据库查询中均正确生效；组合结果为空时有友好提示 | 对应TP-G-001; TP-G-002; TP-G-003; TP-G-004 |
+
+---
+
+## 跨模块测试点
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| AH_REPORT_CROSS_001 | 平台端-监管上报-跨模块 | 验证完整三阶段依赖链端到端验证—后端三重前置状态校验 | P0 | 功能测试 | 1. 准备一条安徽税源地(34)的运单YB202607130001 | 1. 使第一次上报失败（关闭监管平台接口）；2. 尝试调用第二次上报API；3. 查看返回；4. 使第二次上报失败；5. 尝试调用第三次上报API；6. 查看返回 | 运单号: YB202607130001 | 第一次上报失败→第二次上报API返回错误码"前置上报未完成"；第二次上报失败→第三次上报API返回错误码"前置上报（第二次）未完成"；三个阶段不可跳级执行；依赖链校验在后端通过查询report_status表实现，非仅前端控制；每个阶段的阻断/通过状态独立存储 | [AI修正: 历史缺陷防御] - BUG-202607-01 |
+| AH_REPORT_CROSS_002 | 平台端-监管上报-跨模块 | 验证多模块数据一致性—修改源数据后各阶段上报感知变更并使用最新值 | P0 | 功能测试 | 1. 运单YB202607130046初始数据: 司机15188888888、合同金额¥10,000.00、发票金额¥10,300.00 | 1. 第一次上报前修改司机信息（如更换司机手机号）；2. 触发第一次上报，验证使用最新司机信息；3. 财务修改打款金额（¥10,000.00→¥9,500.00）；4. 触发第二次上报，验证使用¥9,500.00；5. 修改发票金额（¥10,300.00→¥10,100.00）；6. 触发第三次上报，验证使用¥10,100.00 | 运单号: YB202607130046; 修改项: 司机/金额/发票 | 第一次上报使用最新司机信息；第二次上报金额为¥9,500.00（非缓存的¥10,000.00）；第三次上报发票金额为¥10,100.00（非旧值）；数据库查询日志可确认各字段的数据来源表（非缓存）；数据库report_record表各阶段记录中的数据与来源表一致 | [AI修正: 历史缺陷防御] - BUG-202607-03 |
+| AH_REPORT_CROSS_003 | 平台端-监管上报-跨模块 | 验证安徽税源地运单完整上报链路—装货到ETC全流程核验通过（冒烟测试） | P0 | 冒烟测试 | 1. 准备一条安徽税源地(34)的完整运单YB202607130001，所有资质有效、合同有效、轨迹正常、支付正常、发票正常 | 1. 装货完成→等待第一次上报→验证状态"已上传"；2. 等待自动修改字段→验证日志中有修改记录；3. 财务打款¥10,000.00→等待第二次上报→验证7类核验全部通过；4. 发票FP202607130001开具→等待第三次上报→验证状态"已上传"；5. 税务抵扣完成→ETC发票ETC202607130001上传→验证状态"已上传" | 运单号: YB202607130001; 金额: ¥10,000.00; 发票: FP202607130001; ETC: ETC202607130001 | 第一次上报成功→第二次上报成功（7核验全通过）→第三次上报成功→ETC上传成功；每个阶段看板数据正确更新；上报日志完整记录全链路；数据库report_record表stage=1/2/3均状态=1；etc_report_record表status=1 | 对应TP-X-003 |
+| AH_REPORT_CROSS_004 | 平台端-监管上报-跨模块 | 验证非安徽税源地运单(云南=28)全部阶段均不触发上报 | P0 | 功能测试 | 1. 准备一条云南税源地(28)的运单YB202607130002，包含完整运输流程 | 1. 装货完成→检查是否触发第一次上报；2. 财务打款→检查是否触发第二次上报；3. 发票开具→检查是否触发第三次上报；4. 税务抵扣→检查是否触发ETC上传；5. 查看看板中是否存在该运单 | 运单号: YB202607130002; 省份代码: 28(云南) | 全部阶段均不触发上报；看板中不显示该云南运单；上报日志中无该运单的任何上报记录；系统无因"不触发"而产生的错误日志或异常告警；云南运单本身的运输流程（装货→运输→卸货→结算）不受影响正常流转 | 对应TP-X-004 |
+| AH_REPORT_CROSS_005 | 平台端-监管上报-跨模块 | 验证多省份部署下安徽(34)和云南(28)上报数据完全隔离 | P1 | 功能测试 | 1. 准备安徽(34)运单YB202607130001和云南(28)运单YB202607130002各1条 | 1. 分别触发两条运单的完整上报流程；2. 查看两个省份的上报日志和数据记录；3. 验证安徽运单的上报目标URL为安徽监管平台，云南运单为云南监管平台 | 安徽: YB202607130001(34); 云南: YB202607130002(28) | 安徽运单仅上报至安徽监管平台(URL含anhui)；云南运单仅上报至云南监管平台(URL含yunnan)；两个省份的report_record表数据通过province_code字段物理/逻辑隔离；省份代码各自独立（安徽=34、云南=28），不混淆 | 对应TP-X-005 |
+| AH_REPORT_CROSS_006 | 平台端-监管上报-跨模块 | 验证定时任务重试与手动触发上报的并发控制—分布式锁机制 | P1 | 功能测试 | 1. 运单YB202607130057第一次上报失败，定时重试任务即将触发第1次重试；2. super_admin在管理端准备手动点击"手动上传" | 1. 在重试任务触发的同时，super_admin点击"手动上传"；2. 观察并发场景下的系统行为 | 运单号: YB202607130057 | 同一时刻仅1个上报请求被执行（通过分布式锁如Redis SETNX控制）；被拒绝的请求返回"上报处理中"提示；不产生重复上报记录；分布式锁正确释放，后续操作可正常进行 | 对应TP-B-014; TP-C-021 |
+| AH_REPORT_CROSS_007 | 平台端-监管上报-跨模块 | 验证回单签收后财务打款前不触发第二次上报—打款完成才触发 | P2 | 功能测试 | 1. 运单YB202607130001第一次上报已完成；2. 回单已签收但财务尚未打款 | 1. 回单签收完成后检查第二次上报列表；2. 财务执行打款后再次检查第二次上报列表；3. 对比两次检查的时间点 | 运单号: YB202607130001; 回单签收时间: 2026-07-12 15:00; 打款时间: 2026-07-12 17:00 | 回单签收完成后第二次上报列表中无该运单记录（未触发）；财务打款完成后第二次上报列表中出现该运单记录（已触发）；上报时间戳接近打款完成时间（如2026-07-12 17:00:05），非回单签收时间 | 对应TP-X-006 |
+
+---
+
+## 测试点→用例映射表
+
+| 测试点ID | 对应的用例编号 | 覆盖状态 |
+| :--- | :--- | :--- |
+| TP-A-001 | AH_REPORT_DASH_001, AH_REPORT_DASH_002, AH_REPORT_DASH_003 | 已覆盖 |
+| TP-A-002 | AH_REPORT_DASH_004 | 已覆盖 |
+| TP-A-003 | AH_REPORT_DASH_005 | 已覆盖 |
+| TP-A-004 | AH_REPORT_DASH_006 | 已覆盖 |
+| TP-A-005 | AH_REPORT_DASH_007 | 已覆盖 |
+| TP-A-006 | AH_REPORT_DASH_008, AH_REPORT_DASH_009 | 已覆盖 |
+| TP-A-007 | AH_REPORT_DASH_010 | 已覆盖 |
+| TP-A-008 | AH_REPORT_DASH_011 | 已覆盖 |
+| TP-A-009 | AH_REPORT_DASH_012 | 已覆盖 |
+| TP-A-010 | AH_REPORT_DASH_013 | 已覆盖 |
+| TP-A-011 | AH_REPORT_DASH_014, AH_REPORT_DASH_015 | 已覆盖 |
+| TP-A-012 | AH_REPORT_DASH_016 | 已覆盖 |
+| TP-A-013 | AH_REPORT_DASH_017 | 已覆盖 |
+| TP-A-014 | AH_REPORT_DASH_018 | 已覆盖 |
+| TP-B-001 | AH_REPORT_R1_001 | 已覆盖 |
+| TP-B-002 | AH_REPORT_R1_002, AH_REPORT_R1_003 | 已覆盖 |
+| TP-B-003 | AH_REPORT_R1_004, AH_REPORT_R1_005, AH_REPORT_R1_021 | 已覆盖 |
+| TP-B-004 | AH_REPORT_R1_003, AH_REPORT_R1_006 | 已覆盖 |
+| TP-B-005 | AH_REPORT_R1_007, AH_REPORT_R1_008 | 已覆盖 |
+| TP-B-006 | AH_REPORT_R1_009 | 已覆盖 |
+| TP-B-007 | AH_REPORT_R1_010 | 已覆盖 |
+| TP-B-008 | AH_REPORT_R1_011 | 已覆盖 |
+| TP-B-009 | AH_REPORT_R1_012 | 已覆盖 |
+| TP-B-010 | AH_REPORT_R1_023 | 已覆盖 |
+| TP-B-011 | AH_REPORT_DASH_014 | 已覆盖（见看板详情弹窗用例） |
+| TP-B-012 | AH_REPORT_DASH_015 | 已覆盖（见看板详情弹窗用例） |
+| TP-B-013 | AH_REPORT_R1_022 | 已覆盖 |
+| TP-B-014 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_CROSS_006 | 已覆盖 |
+| TP-B-015 | AH_REPORT_R1_015 | 已覆盖 |
+| TP-B-016 | AH_REPORT_R1_016 | 已覆盖 |
+| TP-B-017 | AH_REPORT_R1_017 | 已覆盖 |
+| TP-B-018 | AH_REPORT_R1_018 | 已覆盖 |
+| TP-B-019 | AH_REPORT_R1_019, AH_REPORT_R1_020 | 已覆盖 |
+| TP-B-020 | AH_REPORT_R1_024 | 已覆盖 |
+| TP-C-001 | AH_REPORT_R2_001 | 已覆盖 |
+| TP-C-002 | AH_REPORT_R2_002 | 已覆盖 |
+| TP-C-003 | AH_REPORT_R2_003 | 已覆盖 |
+| TP-C-004 | AH_REPORT_R2_004 | 已覆盖 |
+| TP-C-005 | AH_REPORT_R2_004 | 已覆盖 |
+| TP-C-006 | AH_REPORT_R2_005 | 已覆盖 |
+| TP-C-007 | AH_REPORT_R2_006 | 已覆盖 |
+| TP-C-008 | AH_REPORT_R2_007 | 已覆盖 |
+| TP-C-009 | AH_REPORT_R2_008 | 已覆盖 |
+| TP-C-010 | AH_REPORT_R2_009 | 已覆盖 |
+| TP-C-011 | AH_REPORT_R2_010 | 已覆盖 |
+| TP-C-012 | AH_REPORT_R2_011 | 已覆盖 |
+| TP-C-013 | AH_REPORT_R2_012 | 已覆盖 |
+| TP-C-014 | AH_REPORT_R2_013 | 已覆盖 |
+| TP-C-015 | AH_REPORT_R2_014, AH_REPORT_R2_015 | 已覆盖 |
+| TP-C-016 | AH_REPORT_R2_016 | 已覆盖 |
+| TP-C-017 | AH_REPORT_R2_017, AH_REPORT_R2_018 | 已覆盖 |
+| TP-C-018 | AH_REPORT_R2_019, AH_REPORT_R2_020, AH_REPORT_R2_021 | 已覆盖 |
+| TP-C-019 | AH_REPORT_R2_022, AH_REPORT_R2_023 | 已覆盖 |
+| TP-C-020 | AH_REPORT_R2_024 | 已覆盖 |
+| TP-C-021 | AH_REPORT_R2_025, AH_REPORT_CROSS_006 | 已覆盖 |
+| TP-C-022 | AH_REPORT_R2_026 | 已覆盖 |
+| TP-C-023 | AH_REPORT_R2_027 | 已覆盖 |
+| TP-C-024 | AH_REPORT_R2_028 | 已覆盖 |
+| TP-D-001 | AH_REPORT_R3_001 | 已覆盖 |
+| TP-D-002 | AH_REPORT_R3_002 | 已覆盖 |
+| TP-D-003 | AH_REPORT_R3_003 | 已覆盖 |
+| TP-D-004 | AH_REPORT_R3_004, AH_REPORT_R3_005 | 已覆盖 |
+| TP-D-005 | AH_REPORT_R3_006, AH_REPORT_R3_007 | 已覆盖 |
+| TP-D-006 | AH_REPORT_R3_008, AH_REPORT_R3_009 | 已覆盖 |
+| TP-D-007 | AH_REPORT_R3_010 | 已覆盖 |
+| TP-D-008 | AH_REPORT_R3_014 | 已覆盖 |
+| TP-D-009 | AH_REPORT_R3_011 | 已覆盖 |
+| TP-D-010 | AH_REPORT_R3_012 | 已覆盖 |
+| TP-D-011 | AH_REPORT_R3_013 | 已覆盖 |
+| TP-E-001 | AH_REPORT_ETC_001 | 已覆盖 |
+| TP-E-002 | AH_REPORT_ETC_002 | 已覆盖 |
+| TP-E-003 | AH_REPORT_ETC_003 | 已覆盖 |
+| TP-E-004 | AH_REPORT_ETC_004 | 已覆盖 |
+| TP-E-005 | AH_REPORT_ETC_005, AH_REPORT_ETC_006, AH_REPORT_ETC_011, AH_REPORT_ETC_012 | 已覆盖 |
+| TP-E-006 | AH_REPORT_ETC_007 | 已覆盖 |
+| TP-E-007 | AH_REPORT_ETC_008 | 已覆盖 |
+| TP-E-008 | AH_REPORT_ETC_009 | 已覆盖 |
+| TP-E-009 | AH_REPORT_ETC_010 | 已覆盖 |
+| TP-F-001 | AH_REPORT_APL_001 | 已覆盖 |
+| TP-F-002 | AH_REPORT_APL_003 | 已覆盖 |
+| TP-F-003 | AH_REPORT_APL_004, AH_REPORT_APL_005 | 已覆盖 |
+| TP-F-004 | AH_REPORT_APL_006 | 已覆盖 |
+| TP-F-005 | AH_REPORT_APL_007, AH_REPORT_APL_016 | 已覆盖 |
+| TP-F-006 | AH_REPORT_APL_002 | 已覆盖 |
+| TP-F-007 | AH_REPORT_APL_008 | 已覆盖 |
+| TP-F-008 | AH_REPORT_APL_009 | 已覆盖 |
+| TP-F-009 | AH_REPORT_APL_010, AH_REPORT_APL_017 | 已覆盖 |
+| TP-F-010 | AH_REPORT_APL_011 | 已覆盖 |
+| TP-F-011 | AH_REPORT_APL_012, AH_REPORT_APL_013 | 已覆盖 |
+| TP-F-012 | AH_REPORT_APL_005, AH_REPORT_APL_014 | 已覆盖 |
+| TP-F-013 | AH_REPORT_APL_015 | 已覆盖 |
+| TP-G-001 | AH_REPORT_LOG_001, AH_REPORT_LOG_002 | 已覆盖 |
+| TP-G-002 | AH_REPORT_LOG_003 | 已覆盖 |
+| TP-G-003 | AH_REPORT_LOG_004 | 已覆盖 |
+| TP-G-004 | AH_REPORT_LOG_005 | 已覆盖 |
+| TP-G-005 | AH_REPORT_LOG_006 | 已覆盖 |
+| TP-G-006 | AH_REPORT_LOG_007 | 已覆盖 |
+| TP-G-007 | AH_REPORT_LOG_008 | 已覆盖 |
+| TP-G-008 | AH_REPORT_LOG_009 | 已覆盖 |
+| TP-G-009 | AH_REPORT_LOG_010 | 已覆盖 |
+| TP-X-001 | AH_REPORT_CROSS_001 | 已覆盖 |
+| TP-X-002 | AH_REPORT_CROSS_002 | 已覆盖 |
+| TP-X-003 | AH_REPORT_CROSS_003 | 已覆盖 |
+| TP-X-004 | AH_REPORT_CROSS_004 | 已覆盖 |
+| TP-X-005 | AH_REPORT_CROSS_005 | 已覆盖 |
+| TP-X-006 | AH_REPORT_CROSS_007 | 已覆盖 |
+
+所有132个测试点均已映射到至少一条测试用例。
+
+---
+
+## 历史缺陷防御映射表
+
+| 历史缺陷ID | 防御用例 | 备注 |
+| :--- | :--- | :--- |
+| BUG-202607-01（阶段依赖链断裂） | AH_REPORT_R1_007, AH_REPORT_R1_008, AH_REPORT_R2_024, AH_REPORT_R3_006, AH_REPORT_R3_007, AH_REPORT_CROSS_001 | 后端三重前置状态校验覆盖 |
+| BUG-202607-02（重试幂等缺陷） | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009, AH_REPORT_CROSS_006 | 分布式锁+唯一约束+前端防抖覆盖 |
+| BUG-202607-03（跨模块数据不一致） | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_R3_013, AH_REPORT_CROSS_002 | 数据来源溯源验证覆盖 |
+| BUG-202607-04（省份代码硬编码） | AH_REPORT_R1_006, AH_REPORT_CROSS_005 | 省份代码动态配置+多省份隔离覆盖 |
+
+---
+
+## 漏测清单覆盖汇总
+
+| 漏测类别 | 覆盖用例数 | 覆盖状态 |
+| :--- | :--- | :--- |
+| 空值/Null处理 | AH_REPORT_R1_018 (1条) | 已覆盖 |
+| 金额精度 | AH_REPORT_R2_002, AH_REPORT_R3_012, AH_REPORT_ETC_008 (3条) | 已覆盖 |
+| 重复提交/防抖 | AH_REPORT_R1_013, AH_REPORT_R1_014, AH_REPORT_R2_025, AH_REPORT_R3_011, AH_REPORT_ETC_009 (5条) | 已覆盖 |
+| 超时处理 | AH_REPORT_R1_015, AH_REPORT_R1_016, AH_REPORT_APL_015 (3条) | 已覆盖 |
+| 列表字段完整性 | AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_ETC_002, AH_REPORT_APL_003, AH_REPORT_LOG_006 (6条) | 已覆盖 |
+| 查询重置 | AH_REPORT_DASH_010 (1条) | 已覆盖 |
+| 状态与按钮映射 | AH_REPORT_DASH_013, AH_REPORT_R1_012 (2条) | 已覆盖 |
+| 多阶段依赖链 | AH_REPORT_R1_007, AH_REPORT_R2_024, AH_REPORT_R3_007, AH_REPORT_CROSS_001 (4条) | 已覆盖 |
+| 第三方核验逐项覆盖 | AH_REPORT_R2_005~AH_REPORT_R2_023 (14条，7类×通过+异常) + AH_REPORT_R2_030~AH_REPORT_R2_053 (24条，API文档12项补充核验×通过+异常) = 共38条覆盖API文档17项核验 | 已覆盖 |
+| 重试+手动触发并发 | AH_REPORT_R1_013, AH_REPORT_R2_025, AH_REPORT_CROSS_006 (3条) | 已覆盖 |
+| 跨模块数据一致性 | AH_REPORT_R2_002, AH_REPORT_R2_003, AH_REPORT_CROSS_002 (3条) | 已覆盖 |
+| 省份/区域配置隔离 | AH_REPORT_R1_006, AH_REPORT_CROSS_005 (2条) | 已覆盖 |
+| 上报数据字段溯源 | AH_REPORT_R2_002, AH_REPORT_R3_013, AH_REPORT_CROSS_002 (3条) | 已覆盖 |
+| 标签颜色映射 | AH_REPORT_DASH_012, AH_REPORT_R1_023, AH_REPORT_R2_004 (3条) | 已覆盖 |
+| 详情弹窗分组完整性 | AH_REPORT_DASH_014, AH_REPORT_DASH_015, AH_REPORT_R1_022, AH_REPORT_R3_003, AH_REPORT_ETC_003, AH_REPORT_APL_006 (6条) | 已覆盖 |
+| 轨迹数据边界(2~2000) | AH_REPORT_R2_020, AH_REPORT_R2_021, AH_REPORT_R2_022, AH_REPORT_R2_023 (4条) | 已覆盖 |
+| 申诉闭环 | AH_REPORT_APL_001, AH_REPORT_APL_002, AH_REPORT_APL_004 (3条) | 已覆盖 |
+| 操作日志可追溯 | AH_REPORT_LOG_006, AH_REPORT_LOG_007, AH_REPORT_LOG_008, AH_REPORT_LOG_009, AH_REPORT_LOG_010 (5条) | 已覆盖 |
+
+---
+
+> ⚠️ 待确认项：
+> 1. 需求中"异常代码一览表"章节仅有标题无具体内容，需与产品确认完整的异常代码映射表后补充 AH_REPORT_APL_012 的详细验证数据。
+> 2. 自动重试的具体间隔时间（当前用例中使用5s/15s/30s为参考值），需与技术方案确认后更新 AH_REPORT_R1_010, AH_REPORT_R2_026, AH_REPORT_R3_010, AH_REPORT_ETC_007 中的重试间隔。
+> 3. ETC税额边界值（0.01元 → 税额=0.00）的四舍五入规则需与财务确认，更新 AH_REPORT_ETC_008。
+> 4. 申诉超时告警阈值（当前用例中使用7个工作日为参考值）需与产品确认，更新 AH_REPORT_APL_015。
+> 5. 建议在后续需求评审中人工确认安徽运八与现有云南运八上报逻辑是否存在字段/接口冲突。
+> 6. 部分用例中使用的模拟数据（如运单号YB202607130004~YB202607130057等）为测试用例设计时分配的虚拟编号，实际执行时需替换为测试环境中真实存在的运单数据。
+> 7. 涉及省平台回调的用例（如申诉复核反馈、核验结果返回），实际执行时需确认是否有省平台测试环境或mock工具支持。