# 安徽运八需求 — 原型&接口文档交叉分析

> 分析时间: 2026-07-13
> 原型: `E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html`
> 接口文档: `E:\Downloads\网货企业端接口文档（最新）.pdf` (V1.0.2, 2023-04)
> 需求文档: `source_docs/requirements_raw/安徽运八需求.docx`

---

## 一、关键发现总览

| # | 发现 | 严重程度 | 影响范围 |
|:---:|:---|:---:|:---|
| 1 | 核验项数量：需求7类 vs API文档17项 | **P0 阻断** | 第二次上报核验覆盖 |
| 2 | 申诉状态枚举三套不一致 | P1 | 申诉模块全部用例 |
| 3 | 第三次上报列表字段与原型不一致 | P1 | 第三次上报列表验证 |
| 4 | 详情弹窗字段分组/数量与原型不一致 | P1 | 所有详情弹窗用例 |
| 5 | API新增里程申诉接口 | P2 | 遗漏功能覆盖 |
| 6 | 看板申诉状态下拉值与需求不一致 | P1 | 看板筛选用例 |
| 7 | ETC发票详情含"不含税金额"字段 | P2 | ETC详情用例 |
| 8 | 原型看板有checkbox勾选列 | P3 | 看板交互用例 |
| 9 | 接口文档异常代码枚举vs需求异常代码 | P1 | 异常申诉用例 |

---

## 二、核验项对照（重大差异）

### 需求文档描述的7类核验
1. 运单重复核验
2. 车辆资质核验
3. 司机资质核验
4. 集中支付核验
5. 资金流水核验
6. 合同核验
7. 车辆轨迹合规核验

### API文档定义的17项核验（§4.1 异常项ID对照表）

| Code | 名称 | 需求是否提到 |
|:---:|:---|:---:|
| 100 | 委托合同 | 合并为"合同核验" |
| 120 | 承运合同 | 合并为"合同核验" |
| 130 | 实时定位 | ❌ 未提及 |
| 140 | 运单时间逻辑 | ❌ 未提及 |
| 150 | 车辆资质 | ✅ |
| 160 | 道路运输证 | 隐含在车辆资质 |
| 170 | 驾驶证 | 隐含在司机资质 |
| 180 | 从业资格证 | ✅ 司机资质 |
| 190 | 车辆重复 | ❌ 未提及（需求仅有运单重复） |
| 200 | 司机重复 | ❌ 未提及 |
| 210 | 车辆轨迹 | ✅ |
| 220 | 运费收款 | ❌ 未提及 |
| 230 | 公司统一收款 | ❌ 未提及 |
| 240 | 集中支付 | ✅ |
| 250 | 资金流水 | ✅ |
| 260 | 发票信息 | ❌ 未提及（第三次上报相关） |
| 270 | 非通行车辆可开票 | ❌ 未提及 |

> ⚠️ **待确认**: 需求文档将17项核验归纳为7类是否合理？测试点应按需求7类还是API 17项逐项覆盖？建议按API 17项逐项覆盖（因为每项有独立的核验结果和申诉入口）。

---

## 三、申诉状态枚举对照

| 需求文档 | HTML原型 | API文档(§4.4) | API Code |
|:---|:---|:---|:---:|
| 未申诉 | 未申诉 | 未申诉 | 100 |
| 申诉中 | 待省平台反馈 | — | — |
| — | 反馈处理中 | — | — |
| 申诉通过 | 申诉通过 | 审核通过 | 110 |
| 申诉驳回 | 申诉驳回 | 审核不通过 | 120 |
| — | — | 已取消 | 130 |

> ⚠️ **待确认**: 
> - 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？
> - API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？
> - 看板筛选下拉值以哪个为准？

---

## 四、列表字段差异

### 第三次上报列表
| 需求字段 | 原型字段 | 差异 |
|:---|:---|:---|
| 车牌号 | ✅ | — |
| 司机姓名 | ✅ | — |
| 托运方名称 | ✅ | — |
| — | **税率** | 需求未列出 |
| — | **销售方名称** | 需求未列出 |
| — | **受票方名称** | 需求未列出 |
| — | **油气票张数** | 需求未列出 |

原型比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox）。

### 第一次上报列表
需求与原型一致，14字段 + checkbox。

### ETC上传列表
原型字段（10列+checkbox）：货源单号/运单号/托运单号/ETC发票号/交易金额/入口收费站/出口收费站/交易时间/上传状态/操作
**缺少**: 车牌号、司机姓名、托运方名称（需求中列出）、税率（需求中列出）

---

## 五、详情弹窗字段差异

### 第一次上报详情弹窗
| 分组 | 需求字段数 | 原型字段数 | 差异 |
|:---|:---:|:---:|:---|
| 建单信息 | 13 | 10 | 原型无"上游企业委托运输单号""网络货运经营者名称""统一社会信用代码""道路运输经营许可证编号""运输组货方式代码"等 |
| 托运人信息 | 7 | 8 | 原型多了货物名称/重量/体积 |
| 收货方信息 | 5 | 8 | 原型多了联系人/电话/收货时间/签收状态 |
| 司机信息 | 13 | 6 | 原型大幅简化 |
| 车辆信息 | 19 | 8 | 原型大幅简化 |
| 货物信息 | 4/条 | 8/条(卡片式) | 原型多了件数/单价/包装方式/危险货物标志 |
| 保险信息 | 2 | 7 | 原型多了保险类型/金额/有效期起止/保单状态 |
| 异常信息 | 4 | 4 | 一致 |

> ⚠️ **待确认**: 需求文档字段定义来自接口文档（https://www.showdoc.com.cn/2210641821476236/9919735893682511），原型可能是简化版。详细字段数以接口文档为准还是以原型为准？

### 第二次上报详情弹窗
| 分组 | 需求 | 原型 | 差异 |
|:---|:---|:---|:---|
| 资金流水 | 10字段 | 11字段 | 原型多了"实际支付金额" |
| 车辆轨迹 | 6字段/点 | **未展示** | 原型弹窗缺失车辆轨迹信息！ |
| 油气发票 | — | 有 | 需求未在第二次上报中提及油气发票 |

> ⚠️ **待确认**: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？

### 第三次上报详情弹窗
需求分组：运单信息/发票信息(17字段)/油气发票信息(可选)/异常信息
原型分组：运单信息/发票信息(10字段)/ETC发票信息(可选)/异常信息
- **差异**: 原型把"油气发票"换成了"ETC发票信息"，发票信息字段从17减为10

---

## 六、API接口清单

接口文档（V1.0.2）定义了以下接口：

| 接口 | URL | 方法 | 说明 |
|:---|:---|:---:|:---|
| 获取token | /sys/login | POST | JWT认证 |
| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 |
| 提交申诉运单 | /appeal/insert | POST | 发起申诉 |
| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails |
| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 |
| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 |
| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规 |
| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 |
| 运单里程申诉 | /mileageAppeal/insert | POST | **需求未提及的新功能！** |

### 关键API数据结构

#### 异常运单查询响应 (verificationSummary/page)
```
pageRecords[]:
  freightSheetNumber, appealStateId/Name, verificationAbnormalItem,
  createTime, lastVerifyTime, firstVerifyTime, vehicleNumber,
  driverName, driverIdCard, verifyStateId/Name,
  abnormalDetails[]:
    id (异常项ID), name (异常项名称), message (异常原因),
    time (异常时间), state (100=未申诉, 110=申诉中)
```

#### 核验详情响应 (verificationSummary/verificationDetail)
```
details[]:
  verificationCode (核验项编码), verificationName (核验项名称),
  verificationState (核验状态), verificationStateId,
  verificationTime, message (核验信息)
```

---

## 七、需要更新的测试资产

### 测试点更新
1. **TP-C-006~TP-C-019**: 将"7类核验"扩展为"17项核验"逐项覆盖（+20个测试点）
2. **TP-F-xxx**: 申诉状态枚举对齐（确认最终版本后更新）
3. **TP-D-002**: 第三次上报列表字段数修正为原型字段数
4. **TP-E-xxx**: ETC上传列表字段对齐
5. **新增TP**: 里程申诉功能、发票合规查询功能
6. **TP-A-xxx**: 看板申诉状态下拉值对齐

### 测试用例更新
1. 核验项相关用例从14条扩展到34条（17项×2 pass+exception）
2. 申诉状态相关用例枚举值对齐
3. 第三次上报列表字段验证用例更新
4. 新增里程申诉用例
5. 新增发票合规查询用例

### 需求分析更新
1. 核验项从7类更新为17项
2. 申诉状态枚举标注三版本差异
3. 新增API接口清单