4. 数据模型设计：TMS轨迹表与ERP签收表结构及关联键

一致性校验测试的核心基础是数据模型。TMS（运输管理系统）的轨迹节点与ERP（企业资源计划系统）的签收记录，在表结构设计上存在天然差异。本章将详细定义两张核心表的结构、字段含义，并设计用于关联校验的键（运单号、订单号），为后续的校验规则与测试脚本奠定数据基础。

4.1 TMS轨迹表结构设计

TMS轨迹表用于记录运输过程中每个节点的状态变更，包括时间、地点、操作人及异常信息。每一条记录代表一个轨迹节点。

4.2 ERP签收表结构设计

ERP签收表记录最终签收环节的确认信息，通常只包含一次签收动作，但可能包含多次拒收或部分签收的明细。

4.3 关联键设计：运单号与订单号

关联键是跨系统数据一致性的桥梁。本课程采用双关联键策略：运单号（waybill_no） 和 订单号（order_no）。

• 运单号（waybill_no）：在TMS内唯一标识一次运输任务。ERP侧可能通过接口回传或手动录入获得该号。
• 订单号（order_no）：在ERP内唯一标识一笔销售订单。TMS在接收运输任务时，必须携带该订单号。

关联规则如下：

1. 正向匹配：使用 waybill_no 作为主关联键，order_no 作为辅助校验键。当运单号一致时，再验证订单号是否匹配。
2. 反向追溯：当运单号匹配失败时，使用 order_no 进行二次关联，查找是否存在订单号一致但运单号不一致的记录。
3. 异常处理：若两个关联键均无法匹配，则标记为“孤立记录”，需人工介入核查。

4.4 关联键校验逻辑与示例

在实际测试中，关联键的匹配并非总是完美。以下列出三种典型场景及对应的SQL校验逻辑。

4.4.1 场景一：完全匹配

TMS轨迹表中存在 waybill_no 和 order_no 均与ERP签收表一致的记录，且节点编码为“已签收”。

-- 查找完全匹配的记录
SELECT t.waybill_no, t.order_no, t.operate_time AS tms_time, e.sign_time AS erp_time
FROM tms_track t
INNER JOIN erp_sign e ON t.waybill_no = e.waybill_no AND t.order_no = e.order_no
WHERE t.node_code = 'DELIVERED'
  AND ABS(TIMESTAMPDIFF(SECOND, t.operate_time, e.sign_time)) <= 300;

4.4.2 场景二：运单号匹配但订单号不匹配

可能由于系统间数据同步延迟或人工录入错误导致。此时需要标记为“订单号不一致”异常。

-- 查找运单号一致但订单号不一致的记录
SELECT t.waybill_no, t.order_no AS tms_order, e.order_no AS erp_order
FROM tms_track t
INNER JOIN erp_sign e ON t.waybill_no = e.waybill_no
WHERE t.order_no != e.order_no;

4.4.3 场景三：孤立记录

某张运单在TMS中存在轨迹，但在ERP中完全找不到对应的签收记录。

-- 查找TMS中存在但ERP中不存在的运单
SELECT t.waybill_no, t.order_no, MAX(t.operate_time) AS last_time
FROM tms_track t
LEFT JOIN erp_sign e ON t.waybill_no = e.waybill_no
WHERE e.sign_id IS NULL
GROUP BY t.waybill_no, t.order_no;

4.5 数据模型设计总结

本章定义的数据模型是后续所有校验测试的基石。核心要点如下：

• TMS轨迹表：事件驱动，多行记录，包含完整运输链路。
• ERP签收表：结果驱动，单行记录，聚焦最终签收状态。
• 关联键：采用 waybill_no + order_no 双键策略，提高匹配容错率。
• 时间阈值：TMS签收节点时间与ERP签收时间允许 ±5 分钟偏差，超出则视为异常。