2. TMS基础认知
在动手做数据迁移之前，必须先弄清楚我们迁移的到底是什么系统。TMS（Transportation Management System，运输管理系统）是围绕“货物从A点到B点”这一核心过程，对运输计划、执行、结算与优化进行统一管理的专业软件。它既不是简单的“派车记录表”，也不是ERP里的一个运输模块，而是承载运输业务规则、运力资源、计费逻辑与在途数据的独立业务系统。理解TMS的边界，直接决定了迁移时哪些数据必须搬、哪些数据可以重建。
一、TMS的核心功能模块
典型TMS的功能可以按“计划—执行—结算—分析”四条主线来理解。计划侧负责订单接入、运输方式选择、配载与路径规划；执行侧负责承运商指派、调度、在途跟踪与异常处理；结算侧负责运费计算、对账与成本分摊；分析侧则输出时效、成本、承运商绩效等指标。这些模块之间存在明确的数据依赖，迁移时必须按依赖顺序处理。
| 功能模块 | 核心职责 | 关键数据对象 | 迁移优先级 |
|---|---|---|---|
| 订单与计划 | 接收运输需求、生成运输计划 | 运输订单、计划单 | 高 |
| 调度与执行 | 指派承运商、车辆、司机 | 运单、任务、在途事件 | 高 |
| 计费与结算 | 运费计算、对账、成本归集 | 费率表、计费明细、对账单 | 中 |
| 跟踪与异常 | 在途定位、异常上报与处理 | 轨迹点、异常单 | 中 |
| 主数据 | 承运商、车辆、司机、地点 | 主数据档案 | 最高 |
| 分析与报表 | 时效、成本、绩效分析 | 指标快照、报表 | 低 |
二、常见产品类型与选型差异
市面上的TMS大致分为三类：一是标准化SaaS产品，开箱即用、按单或按年付费，适合运输模式相对标准的企业；二是行业化套件，如面向快递快运、冷链、大宗物流的专用TMS，内置行业规则；三是企业自研或深度定制平台，通常与ERP、WMS深度耦合。产品类型不同，数据模型差异极大。例如SaaS产品的运单状态机往往是固定的，而自研系统可能允许自定义状态流转。迁移前必须确认目标系统的状态机与字段约束，否则历史数据会因状态不合法而被拒绝写入。
三、TMS与ERP、WMS、OMS的关系
这四个系统在供应链中各有分工，又通过接口紧密协作。OMS负责接收客户订单并做订单拆分与分配；WMS负责仓库内的收货、上架、拣货、出库；TMS负责出库后的运输执行；ERP则是财务、采购、库存与主数据的后台。它们之间的数据流可以概括为：OMS生成出库需求，WMS完成出库并回传出库确认，TMS据此创建运单并执行运输，最终将运费与签收信息回传ERP进行结算。
从迁移视角看，这种关系意味着TMS的历史数据往往不是孤立的。运单上挂着OMS的订单号、WMS的出库单号、ERP的物料与成本中心。如果只迁移TMS自身表结构，而忽略这些外部关联键，上线后就会出现“运单查不到订单”“运费无法归集”的问题。因此迁移方案中必须明确哪些外部键需要保留、哪些可以重新映射。
四、典型应用场景与迁移影响
不同运输场景对TMS的数据要求差异明显。例如，整车运输关注车辆与司机绑定、在途轨迹；零担运输关注分拨中心、中转与拼载；跨境运输则涉及报关、多段运输与多币种结算。场景越复杂，历史数据的字段越多、状态越丰富，迁移时的清洗规则也越复杂。
- 整车直送：运单结构简单，迁移重点在车辆与司机主数据。
- 零担分拨：存在中转与拼载关系，迁移需保留父子运单关联。
- 冷链运输：涉及温度记录与时效要求，历史轨迹数据量大。
- 跨境多式联运：多段运输、多币种，结算数据迁移风险最高。
总结来说，TMS是运输业务的操作系统，它与OMS、WMS、ERP共同构成供应链执行闭环。理解它的功能模块、产品类型与系统关系，是制定迁移策略的前提。下一阶段的工作，就是基于这些认知，梳理出需要迁移的具体数据对象与依赖顺序。