简介这份《TMS运输管理系统.pptx》是一套面向物流运输行业从业者、物流信息化项目人员及供应链管理学习者的入门级演示文档。TMS即Transportation Management System系统讲解其在运输公司与企业自有运输队中的应用价值帮助读者理解如何通过订单管理、调度分配、行车管理、GPS车辆定位、车辆与人员管理等模块提升运作效率、降低运输成本。文档依次梳理系统介绍、适用业务类型、功能模块及特点、系统架构、服务与实施、产品服务体系六大板块涵盖集港运输、特种运输、危品运输、零担运输、干线运输、市内配送等业务模式并延伸至食品冷链、化工物流、第三方物流、电商物流等场景还涉及配载优化算法、GIS地图与智能APP动态调度、J2EE与SOA技术架构、OMS/WMS/BMS等一体化产品体系。资源包为1个pptx文件约1.45MB共17页结构清晰、便于演示汇报。目前已有1012人学习下载适合快速建立对运输管理系统整体框架的认知。1. TMS运输管理系统到底解决什么问题一张运单从客服下单到财务收到回单中间要经过接单、调度派车、装车、在途、到场、签收、对账七个节点。早期物流公司靠 Excel 加微信群完成这套动作调度员的脑子就是路由引擎漏单、错派、运费算错全凭电话追。TMS 运输管理系统要做的是把这条链路固化成三样东西能约束流转的运单状态机、能把车货匹配起来的调度规则、能按合同算出应收应付的计费引擎。它服务的对象很明确——日均发运量过百单、车辆靠自有加外协混合调度、需要和上下游系统对接的物流企业与货主 IT 团队。把这三样东西怎么落地讲清楚比背功能清单有用得多下面按建模、调度、在途、结算的顺序拆。2. TMS 运输管理系统的领域建模与运单状态机设计建模错一步后面调度和结算全要返工。见过太多团队把客户订单直接当运单用做到拼车场景就卡死——三张客户订单要合成一趟车订单粒度和运输粒度对不上。这一章先把三层结构拆开再落到 MySQL 表结构和状态机代码上。2.1 为什么必须拆成订单、运单、任务三层客户下的叫委托单描述的是「我要运什么、从哪到哪、什么时候到」。承运方执行的是运单描述的是「这票货由谁的车、什么时候装、走哪条线」。一车装多单时再抽一层车次任务把同一趟车的多个运单绑在一起。三层拆开的好处是任意一层变化不影响其他层客户改送货时间只动委托单调度换车只动运单车辆临时故障换车只动车次。拆分的关键判断点是「合并与拆分会不会发生」。如果业务里存在一车多单、一单多车超大批量拆车就必须拆如果永远是一单一车一司机可以合并但不能省状态机。2.2 运单主表的 MySQL 建表与索引取舍CREATE TABLE tms_waybill ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, waybill_no VARCHAR(32) NOT NULL COMMENT 运单号业务唯一键, order_id BIGINT UNSIGNED NOT NULL COMMENT 来源客户委托单, status TINYINT NOT NULL DEFAULT 10 COMMENT 10待调度 20已派车 30已装车 40在途 50已到场 60已签收 90已取消, origin_code VARCHAR(12) NOT NULL COMMENT 起运地行政区划编码, dest_code VARCHAR(12) NOT NULL COMMENT 目的地行政区划编码, plan_pickup_time DATETIME NOT NULL COMMENT 计划提货时间, plan_arrive_time DATETIME NOT NULL COMMENT 计划到达时间, vehicle_id BIGINT UNSIGNED DEFAULT NULL COMMENT 指派车辆, driver_id BIGINT UNSIGNED DEFAULT NULL COMMENT 指派司机, total_weight DECIMAL(12,3) NOT NULL DEFAULT 0 COMMENT 总重 kg, total_volume DECIMAL(12,4) NOT NULL DEFAULT 0 COMMENT 总体积 m³, freight_amount DECIMAL(14,2) DEFAULT NULL COMMENT 应收运费, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_waybill_no (waybill_no), KEY idx_status_pickup (status, plan_pickup_time), KEY idx_vehicle_status (vehicle_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运单主表;idx_status_pickup是给调度池扫描用的调度员打开待派车列表查询条件固定是「状态等于待调度按提货时间排序」联合索引能把范围扫描压到最小。idx_vehicle_status支撑车辆台账页查某台车当前挂了几票未完成运单。重量体积用 DECIMAL 不用 FLOAT运费算到分,浮点误差在对账时会被财务追着改。注意运单号不要用自增 ID 拼日期用独立的发号器或号段服务自增 ID 会暴露单量。2.3 用状态机替代散落的 if-else 流转运单状态是有限集合转移路径也是有限的硬编码 if-else 的问题是新增状态要全表搜漏改一处就是脏数据。正确做法是把转移关系声明成表。public enum WaybillStatus { WAIT_DISPATCH(10), DISPATCHED(20), LOADED(30), IN_TRANSIT(40), ARRIVED(50), SIGNED(60), CANCELED(90); private final int code; WaybillStatus(int code) { this.code code; } public int code() { return code; } // 声明式转移表key 是当前状态value 是允许到达的状态集合 private static final MapWaybillStatus, SetWaybillStatus TRANSITIONS Map.of( WAIT_DISPATCH, EnumSet.of(DISPATCHED, CANCELED), DISPATCHED, EnumSet.of(LOADED, WAIT_DISPATCH, CANCELED), LOADED, EnumSet.of(IN_TRANSIT, DISPATCHED), IN_TRANSIT, EnumSet.of(ARRIVED, LOADED), ARRIVED, EnumSet.of(SIGNED, IN_TRANSIT), SIGNED, EnumSet.noneOf(WaybillStatus.class), CANCELED, EnumSet.noneOf(WaybillStatus.class) ); public boolean canTransferTo(WaybillStatus target) { return TRANSITIONS.getOrDefault(this, Set.of()).contains(target); } }每次状态变更先调canTransferTo校验再走一条带乐观锁的 UPDATE把校验和写入做成原子操作UPDATE tms_waybill SET status #{toStatus}, version version 1 WHERE id #{id} AND status #{fromStatus} AND version #{version};返回影响行数为 0说明运单被另一个请求先改了此时应该重新加载再判断而不是重试覆盖。这个模式在派车和签收两个高并发入口是必需的调度员双击派车按钮、司机重复点签收都会打到同一条记录。参数说明fromStatus是读取时的旧状态version是读取时的版本号两个条件共同保证 CAS 语义。toStatus必须通过转移表校验否则回退路径比如在途回到已装车会被错误允许。2.4 状态变更事件的幂等与审计外部系统司机 App、GPS 平台、客户 ERP回调状态时网络重试几乎必然带来重复消息。做法是单独建事件表用业务唯一键做幂等字段类型说明event_idVARCHAR(64)上游消息 ID唯一键waybill_noVARCHAR(32)运单号event_typeVARCHAR(24)事件类型如 PICKUP、ARRIVEpayloadJSON原始报文便于追溯occur_timeDATETIME事件发生时间非入库时间唯一键建在(waybill_no, event_type, occur_time)上重复回调直接触发唯一键冲突捕获后丢弃即可。保留payload原报文的价值在于排错——司机说签收了系统没显示先看事件表里有没有这条记录再判断是链路问题还是业务问题。3. TMS 运输管理系统的智能调度与车辆配载实现调度是 TMS 里最容易被高估的部分。真实业务里完全自动派车的场景很少多数是自己车固定线路加外协车临时补位算法的定位是给调度员几个候选方案而不是替他做决定。这一章给出能跑起来的路径排序和配载逻辑以及参数该怎么调。3.1 调度必须同时满足的三个硬约束时间窗、载重体积、车型限制三个约束缺一不可。时间窗决定能不能按时到载重体积决定这一趟装不装得下车型决定货物能不能上车冷链、危化品、超限货。约束数据来源违反后果时间窗委托单要求的提送货时段客户拒收、产生等待费载重/体积货物明细汇总超载被查、压坏货物车型/资质车辆档案违规运输实际排线时先用车型过滤候选车再用载重体积做装箱最后用时间窗校验排序结果。顺序颠倒会做大量无效计算。3.2 多点提送的路径排序最近邻加 2-opt一趟车提三个点送两个点顺序组合是 5 的阶乘暴力枚举在点数多时不可行。工程上用最近邻构造初始解再用 2-opt 消除交叉边几十个点以内毫秒级出结果。import math def haversine(a, b): 两点球面距离返回公里。a、b 为 (lat, lng) R 6371.0 lat1, lon1 math.radians(a[0]), math.radians(a[1]) lat2, lon2 math.radians(b[0]), math.radians(b[1]) dlat, dlon lat2 - lat1, lon2 - lon1 h math.sin(dlat/2)**2 math.cos(lat1)*math.cos(lat2)*math.sin(dlon/2)**2 return 2 * R * math.asin(math.sqrt(h)) def route_cost(route, points, start): 按顺序走完所有点的总里程 total, cur 0.0, start for idx in route: total haversine(cur, points[idx]) cur points[idx] return total def nearest_neighbor(start, points): 最近邻构造初始路径 unvisited, route, cur list(range(len(points))), [], start while unvisited: nxt min(unvisited, keylambda i: haversine(cur, points[i])) route.append(nxt) cur points[nxt] unvisited.remove(nxt) return route def two_opt(route, points, start, max_iter200): 2-opt 局部搜索翻转子路径消除交叉 best, improved, it route[:], True, 0 while improved and it max_iter: improved, it False, it 1 for i in range(len(best) - 1): for j in range(i 1, len(best)): candidate best[:i1] best[i1:j1][::-1] best[j1:] if route_cost(candidate, points, start) route_cost(best, points, start): best, improved candidate, True return best逻辑说明nearest_neighbor每次都选距离当前点最近的未访问点构造快但容易陷入局部最优two_opt反复尝试翻转任意子路径一旦发现总里程变短就接受直到一轮扫描没有任何改进或达到max_iter。参数说明max_iter是外层迭代上限控制最坏耗时。2-opt 每轮是 O(n²) 次候选评估每次评估是 O(n)点数超过 60 时要把max_iter压到 50 以内或者改用带时间窗的插入启发式。注意算距离一定要用球面公式或投影后的平面坐标直接拿经纬度当平面算纬度高的地区误差能到百分之几十。3.3 多车配载的装箱近似一台车装多个运单本质是带约束的装箱。按体积和重量双维度约束用「先重后轻、先大后小」的降序首次适应运单按重量降序排列逐个尝试放进剩余载重够且剩余体积够的车放不下就开新车。排序键取max(weight / remainWeight, volume / remainVolume)决定优先塞哪台车能让各车装载率更均衡。不要按运单号顺序装那是最差解。3.4 调度参数与效果验证空驶率车辆从当前位置到第一个提货点的距离除以总里程超过 30% 就要考虑换车。装载率实际装载重量除以核定载重低于 60% 建议并单。准时率实际到达时间落在计划时间窗内的比例这个指标比总里程更能反映排线质量。把这几个指标做成调度看板每次算法调整后对比一周数据比单看某一趟的结果可靠。4. TMS 运输管理系统在途跟踪与运单状态回传在途跟踪的价值不在于看车在哪而在于自动推进运单状态。车到了厂区自动置为已到场司机签收自动置为已签收减少人工点按钮。这一章讲定位数据落库、围栏判定和回传去重。4.1 车载定位数据的接入与批量落库定位点上报频率一般在 10 到 30 秒一个点一台车一天产生几千个点几百台车就是百万级写入。单条 INSERT 会被打爆做法是应用层攒批每 500 条或每 2 秒 flush 一次用多值 INSERT 或 LOAD DATA 写入。INSERT INTO tms_gps_point (vehicle_id, waybill_no, lat, lng, speed, direction, report_time) VALUES (1001, WB20240115001, 31.230416, 121.473701, 62.5, 180, 2024-01-15 09:12:30), (1001, WB20240115001, 31.231002, 121.475330, 58.0, 182, 2024-01-15 09:13:00);坐标统一存 WGS84前端展示再按地图底图做一次偏移转换混存坐标系是轨迹画歪的最常见原因。4.2 电子围栏的判定与防抖圆形围栏判定最简单距离小于半径即认为在围栏内public final class GeofenceUtil { private static final double EARTH_RADIUS_M 6371000.0; /** 判断坐标是否落在圆形围栏内返回距圆心米数 */ public static double distanceToCenter(double lat, double lng, double centerLat, double centerLng) { double dLat Math.toRadians(lat - centerLat); double dLng Math.toRadians(lng - centerLng); double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(centerLat)) * Math.cos(Math.toRadians(lat)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 2 * EARTH_RADIUS_M * Math.asin(Math.sqrt(a)); } /** 连续 inStreak 个点在内才判定到达防止 GPS 漂移误触发 */ public static boolean arrived(double lat, double lng, double centerLat, double centerLng, double radiusMeter, int streak, int required) { return distanceToCenter(lat, lng, centerLat, centerLng) radiusMeter streak required; } }参数说明radiusMeter是围栏半径厂区一般设 300 到 500 米太小会因定位精度不够漏判太大则车还在路上就触发了。required是防抖阈值取 3 表示连续三个上报点都在围栏内才确认到达一个点算一次按 30 秒频次就是 90 秒确认延迟这个延迟业务上完全能接受。4.3 轨迹存储选型宽表还是时序库方案写入吞吐查询灵活性运维成本MySQL 按月分表中高可随意关联运单低复用现有实例列式时序库高时间范围查询快关联弱需要额外集群日均点位低于 500 万时MySQL 按vehicle_id哈希加月份分表足够用历史数据超过半年归档冷存。超过这个量级再引入时序库并且只把原始点位放进去运单维度的汇总结果仍留在业务库。4.4 状态回传的限流、去重与补传司机 App 在山区弱网环境下会重复上报服务端必须做三件事按运单号加事件类型做 Redis 短锁防并发、按事件表唯一键做幂等、失败消息进重试队列按指数退避重投。提示重试队列的消息要带原始occur_time不能用来重试的时间否则补传的历史状态会把运单时间线打乱。5. TMS 运费结算引擎的表达式化与对账技巧运费算不对是 TMS 上线后投诉最多的点根源在于把计费逻辑硬编码在代码里客户一改合同就得发版。进阶做法是把计费合同抽象成规则表达式按运单维度匹配规则、代入变量求值。规则结构一般是「匹配条件 计价公式」两部分。匹配条件用运单属性做谓词比如起运地属于华东、货物类型是普货、重量区间在 1 到 5 吨计价公式用重量、体积、里程、区域系数做四则运算。规则按优先级排序命中第一条即返回。判断命中哪条规则时不要一条条试算先把条件拆成可索引的维度。上面这张表把起运地、目的地区域、货物类型三个维度建联合索引一次查询捞出候选规则再在内存里做精细匹配规则上千条时性能差别很明显。字段说明rule_code规则编号业务可读match_origin起运地区域编码空表示不限match_dest目的地区域编码空表示不限cargo_type货物类型空表示不限formula计价表达式如weight * 0.8 distance * 1.2priority优先级数值小的先匹配结算最怕的是重复计费和漏计费。重复计费靠幂等解决以「运单号 计费周期」做唯一键结算任务重跑时先查已结算记录再执行。漏计费靠对账发现每天跑一条差异 SQL-- 找出已签收但未生成结算单的运单 SELECT w.waybill_no, w.freight_amount, w.actual_arrive_time FROM tms_waybill w LEFT JOIN tms_settlement s ON s.waybill_no w.waybill_no WHERE w.status 60 AND w.actual_arrive_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND s.id IS NULL;这条查询每天凌晨跑一次结果非空就告警。反过来再查一条「结算金额与运单应收金额不一致」的两个方向都覆盖住账基本就平了。真正难处理的是改单——运单签收后客户改重量已结算的单子要做冲红再重算冲红单和原单用同一个结算批次号串起来财务核账时才追得清。本文还有配套的精品资源点击获取
TMS运输管理系统实战：运单状态机、智能调度与结算引擎
简介这份《TMS运输管理系统.pptx》是一套面向物流运输行业从业者、物流信息化项目人员及供应链管理学习者的入门级演示文档。TMS即Transportation Management System系统讲解其在运输公司与企业自有运输队中的应用价值帮助读者理解如何通过订单管理、调度分配、行车管理、GPS车辆定位、车辆与人员管理等模块提升运作效率、降低运输成本。文档依次梳理系统介绍、适用业务类型、功能模块及特点、系统架构、服务与实施、产品服务体系六大板块涵盖集港运输、特种运输、危品运输、零担运输、干线运输、市内配送等业务模式并延伸至食品冷链、化工物流、第三方物流、电商物流等场景还涉及配载优化算法、GIS地图与智能APP动态调度、J2EE与SOA技术架构、OMS/WMS/BMS等一体化产品体系。资源包为1个pptx文件约1.45MB共17页结构清晰、便于演示汇报。目前已有1012人学习下载适合快速建立对运输管理系统整体框架的认知。1. TMS运输管理系统到底解决什么问题一张运单从客服下单到财务收到回单中间要经过接单、调度派车、装车、在途、到场、签收、对账七个节点。早期物流公司靠 Excel 加微信群完成这套动作调度员的脑子就是路由引擎漏单、错派、运费算错全凭电话追。TMS 运输管理系统要做的是把这条链路固化成三样东西能约束流转的运单状态机、能把车货匹配起来的调度规则、能按合同算出应收应付的计费引擎。它服务的对象很明确——日均发运量过百单、车辆靠自有加外协混合调度、需要和上下游系统对接的物流企业与货主 IT 团队。把这三样东西怎么落地讲清楚比背功能清单有用得多下面按建模、调度、在途、结算的顺序拆。2. TMS 运输管理系统的领域建模与运单状态机设计建模错一步后面调度和结算全要返工。见过太多团队把客户订单直接当运单用做到拼车场景就卡死——三张客户订单要合成一趟车订单粒度和运输粒度对不上。这一章先把三层结构拆开再落到 MySQL 表结构和状态机代码上。2.1 为什么必须拆成订单、运单、任务三层客户下的叫委托单描述的是「我要运什么、从哪到哪、什么时候到」。承运方执行的是运单描述的是「这票货由谁的车、什么时候装、走哪条线」。一车装多单时再抽一层车次任务把同一趟车的多个运单绑在一起。三层拆开的好处是任意一层变化不影响其他层客户改送货时间只动委托单调度换车只动运单车辆临时故障换车只动车次。拆分的关键判断点是「合并与拆分会不会发生」。如果业务里存在一车多单、一单多车超大批量拆车就必须拆如果永远是一单一车一司机可以合并但不能省状态机。2.2 运单主表的 MySQL 建表与索引取舍CREATE TABLE tms_waybill ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, waybill_no VARCHAR(32) NOT NULL COMMENT 运单号业务唯一键, order_id BIGINT UNSIGNED NOT NULL COMMENT 来源客户委托单, status TINYINT NOT NULL DEFAULT 10 COMMENT 10待调度 20已派车 30已装车 40在途 50已到场 60已签收 90已取消, origin_code VARCHAR(12) NOT NULL COMMENT 起运地行政区划编码, dest_code VARCHAR(12) NOT NULL COMMENT 目的地行政区划编码, plan_pickup_time DATETIME NOT NULL COMMENT 计划提货时间, plan_arrive_time DATETIME NOT NULL COMMENT 计划到达时间, vehicle_id BIGINT UNSIGNED DEFAULT NULL COMMENT 指派车辆, driver_id BIGINT UNSIGNED DEFAULT NULL COMMENT 指派司机, total_weight DECIMAL(12,3) NOT NULL DEFAULT 0 COMMENT 总重 kg, total_volume DECIMAL(12,4) NOT NULL DEFAULT 0 COMMENT 总体积 m³, freight_amount DECIMAL(14,2) DEFAULT NULL COMMENT 应收运费, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_waybill_no (waybill_no), KEY idx_status_pickup (status, plan_pickup_time), KEY idx_vehicle_status (vehicle_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运单主表;idx_status_pickup是给调度池扫描用的调度员打开待派车列表查询条件固定是「状态等于待调度按提货时间排序」联合索引能把范围扫描压到最小。idx_vehicle_status支撑车辆台账页查某台车当前挂了几票未完成运单。重量体积用 DECIMAL 不用 FLOAT运费算到分,浮点误差在对账时会被财务追着改。注意运单号不要用自增 ID 拼日期用独立的发号器或号段服务自增 ID 会暴露单量。2.3 用状态机替代散落的 if-else 流转运单状态是有限集合转移路径也是有限的硬编码 if-else 的问题是新增状态要全表搜漏改一处就是脏数据。正确做法是把转移关系声明成表。public enum WaybillStatus { WAIT_DISPATCH(10), DISPATCHED(20), LOADED(30), IN_TRANSIT(40), ARRIVED(50), SIGNED(60), CANCELED(90); private final int code; WaybillStatus(int code) { this.code code; } public int code() { return code; } // 声明式转移表key 是当前状态value 是允许到达的状态集合 private static final MapWaybillStatus, SetWaybillStatus TRANSITIONS Map.of( WAIT_DISPATCH, EnumSet.of(DISPATCHED, CANCELED), DISPATCHED, EnumSet.of(LOADED, WAIT_DISPATCH, CANCELED), LOADED, EnumSet.of(IN_TRANSIT, DISPATCHED), IN_TRANSIT, EnumSet.of(ARRIVED, LOADED), ARRIVED, EnumSet.of(SIGNED, IN_TRANSIT), SIGNED, EnumSet.noneOf(WaybillStatus.class), CANCELED, EnumSet.noneOf(WaybillStatus.class) ); public boolean canTransferTo(WaybillStatus target) { return TRANSITIONS.getOrDefault(this, Set.of()).contains(target); } }每次状态变更先调canTransferTo校验再走一条带乐观锁的 UPDATE把校验和写入做成原子操作UPDATE tms_waybill SET status #{toStatus}, version version 1 WHERE id #{id} AND status #{fromStatus} AND version #{version};返回影响行数为 0说明运单被另一个请求先改了此时应该重新加载再判断而不是重试覆盖。这个模式在派车和签收两个高并发入口是必需的调度员双击派车按钮、司机重复点签收都会打到同一条记录。参数说明fromStatus是读取时的旧状态version是读取时的版本号两个条件共同保证 CAS 语义。toStatus必须通过转移表校验否则回退路径比如在途回到已装车会被错误允许。2.4 状态变更事件的幂等与审计外部系统司机 App、GPS 平台、客户 ERP回调状态时网络重试几乎必然带来重复消息。做法是单独建事件表用业务唯一键做幂等字段类型说明event_idVARCHAR(64)上游消息 ID唯一键waybill_noVARCHAR(32)运单号event_typeVARCHAR(24)事件类型如 PICKUP、ARRIVEpayloadJSON原始报文便于追溯occur_timeDATETIME事件发生时间非入库时间唯一键建在(waybill_no, event_type, occur_time)上重复回调直接触发唯一键冲突捕获后丢弃即可。保留payload原报文的价值在于排错——司机说签收了系统没显示先看事件表里有没有这条记录再判断是链路问题还是业务问题。3. TMS 运输管理系统的智能调度与车辆配载实现调度是 TMS 里最容易被高估的部分。真实业务里完全自动派车的场景很少多数是自己车固定线路加外协车临时补位算法的定位是给调度员几个候选方案而不是替他做决定。这一章给出能跑起来的路径排序和配载逻辑以及参数该怎么调。3.1 调度必须同时满足的三个硬约束时间窗、载重体积、车型限制三个约束缺一不可。时间窗决定能不能按时到载重体积决定这一趟装不装得下车型决定货物能不能上车冷链、危化品、超限货。约束数据来源违反后果时间窗委托单要求的提送货时段客户拒收、产生等待费载重/体积货物明细汇总超载被查、压坏货物车型/资质车辆档案违规运输实际排线时先用车型过滤候选车再用载重体积做装箱最后用时间窗校验排序结果。顺序颠倒会做大量无效计算。3.2 多点提送的路径排序最近邻加 2-opt一趟车提三个点送两个点顺序组合是 5 的阶乘暴力枚举在点数多时不可行。工程上用最近邻构造初始解再用 2-opt 消除交叉边几十个点以内毫秒级出结果。import math def haversine(a, b): 两点球面距离返回公里。a、b 为 (lat, lng) R 6371.0 lat1, lon1 math.radians(a[0]), math.radians(a[1]) lat2, lon2 math.radians(b[0]), math.radians(b[1]) dlat, dlon lat2 - lat1, lon2 - lon1 h math.sin(dlat/2)**2 math.cos(lat1)*math.cos(lat2)*math.sin(dlon/2)**2 return 2 * R * math.asin(math.sqrt(h)) def route_cost(route, points, start): 按顺序走完所有点的总里程 total, cur 0.0, start for idx in route: total haversine(cur, points[idx]) cur points[idx] return total def nearest_neighbor(start, points): 最近邻构造初始路径 unvisited, route, cur list(range(len(points))), [], start while unvisited: nxt min(unvisited, keylambda i: haversine(cur, points[i])) route.append(nxt) cur points[nxt] unvisited.remove(nxt) return route def two_opt(route, points, start, max_iter200): 2-opt 局部搜索翻转子路径消除交叉 best, improved, it route[:], True, 0 while improved and it max_iter: improved, it False, it 1 for i in range(len(best) - 1): for j in range(i 1, len(best)): candidate best[:i1] best[i1:j1][::-1] best[j1:] if route_cost(candidate, points, start) route_cost(best, points, start): best, improved candidate, True return best逻辑说明nearest_neighbor每次都选距离当前点最近的未访问点构造快但容易陷入局部最优two_opt反复尝试翻转任意子路径一旦发现总里程变短就接受直到一轮扫描没有任何改进或达到max_iter。参数说明max_iter是外层迭代上限控制最坏耗时。2-opt 每轮是 O(n²) 次候选评估每次评估是 O(n)点数超过 60 时要把max_iter压到 50 以内或者改用带时间窗的插入启发式。注意算距离一定要用球面公式或投影后的平面坐标直接拿经纬度当平面算纬度高的地区误差能到百分之几十。3.3 多车配载的装箱近似一台车装多个运单本质是带约束的装箱。按体积和重量双维度约束用「先重后轻、先大后小」的降序首次适应运单按重量降序排列逐个尝试放进剩余载重够且剩余体积够的车放不下就开新车。排序键取max(weight / remainWeight, volume / remainVolume)决定优先塞哪台车能让各车装载率更均衡。不要按运单号顺序装那是最差解。3.4 调度参数与效果验证空驶率车辆从当前位置到第一个提货点的距离除以总里程超过 30% 就要考虑换车。装载率实际装载重量除以核定载重低于 60% 建议并单。准时率实际到达时间落在计划时间窗内的比例这个指标比总里程更能反映排线质量。把这几个指标做成调度看板每次算法调整后对比一周数据比单看某一趟的结果可靠。4. TMS 运输管理系统在途跟踪与运单状态回传在途跟踪的价值不在于看车在哪而在于自动推进运单状态。车到了厂区自动置为已到场司机签收自动置为已签收减少人工点按钮。这一章讲定位数据落库、围栏判定和回传去重。4.1 车载定位数据的接入与批量落库定位点上报频率一般在 10 到 30 秒一个点一台车一天产生几千个点几百台车就是百万级写入。单条 INSERT 会被打爆做法是应用层攒批每 500 条或每 2 秒 flush 一次用多值 INSERT 或 LOAD DATA 写入。INSERT INTO tms_gps_point (vehicle_id, waybill_no, lat, lng, speed, direction, report_time) VALUES (1001, WB20240115001, 31.230416, 121.473701, 62.5, 180, 2024-01-15 09:12:30), (1001, WB20240115001, 31.231002, 121.475330, 58.0, 182, 2024-01-15 09:13:00);坐标统一存 WGS84前端展示再按地图底图做一次偏移转换混存坐标系是轨迹画歪的最常见原因。4.2 电子围栏的判定与防抖圆形围栏判定最简单距离小于半径即认为在围栏内public final class GeofenceUtil { private static final double EARTH_RADIUS_M 6371000.0; /** 判断坐标是否落在圆形围栏内返回距圆心米数 */ public static double distanceToCenter(double lat, double lng, double centerLat, double centerLng) { double dLat Math.toRadians(lat - centerLat); double dLng Math.toRadians(lng - centerLng); double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(centerLat)) * Math.cos(Math.toRadians(lat)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 2 * EARTH_RADIUS_M * Math.asin(Math.sqrt(a)); } /** 连续 inStreak 个点在内才判定到达防止 GPS 漂移误触发 */ public static boolean arrived(double lat, double lng, double centerLat, double centerLng, double radiusMeter, int streak, int required) { return distanceToCenter(lat, lng, centerLat, centerLng) radiusMeter streak required; } }参数说明radiusMeter是围栏半径厂区一般设 300 到 500 米太小会因定位精度不够漏判太大则车还在路上就触发了。required是防抖阈值取 3 表示连续三个上报点都在围栏内才确认到达一个点算一次按 30 秒频次就是 90 秒确认延迟这个延迟业务上完全能接受。4.3 轨迹存储选型宽表还是时序库方案写入吞吐查询灵活性运维成本MySQL 按月分表中高可随意关联运单低复用现有实例列式时序库高时间范围查询快关联弱需要额外集群日均点位低于 500 万时MySQL 按vehicle_id哈希加月份分表足够用历史数据超过半年归档冷存。超过这个量级再引入时序库并且只把原始点位放进去运单维度的汇总结果仍留在业务库。4.4 状态回传的限流、去重与补传司机 App 在山区弱网环境下会重复上报服务端必须做三件事按运单号加事件类型做 Redis 短锁防并发、按事件表唯一键做幂等、失败消息进重试队列按指数退避重投。提示重试队列的消息要带原始occur_time不能用来重试的时间否则补传的历史状态会把运单时间线打乱。5. TMS 运费结算引擎的表达式化与对账技巧运费算不对是 TMS 上线后投诉最多的点根源在于把计费逻辑硬编码在代码里客户一改合同就得发版。进阶做法是把计费合同抽象成规则表达式按运单维度匹配规则、代入变量求值。规则结构一般是「匹配条件 计价公式」两部分。匹配条件用运单属性做谓词比如起运地属于华东、货物类型是普货、重量区间在 1 到 5 吨计价公式用重量、体积、里程、区域系数做四则运算。规则按优先级排序命中第一条即返回。判断命中哪条规则时不要一条条试算先把条件拆成可索引的维度。上面这张表把起运地、目的地区域、货物类型三个维度建联合索引一次查询捞出候选规则再在内存里做精细匹配规则上千条时性能差别很明显。字段说明rule_code规则编号业务可读match_origin起运地区域编码空表示不限match_dest目的地区域编码空表示不限cargo_type货物类型空表示不限formula计价表达式如weight * 0.8 distance * 1.2priority优先级数值小的先匹配结算最怕的是重复计费和漏计费。重复计费靠幂等解决以「运单号 计费周期」做唯一键结算任务重跑时先查已结算记录再执行。漏计费靠对账发现每天跑一条差异 SQL-- 找出已签收但未生成结算单的运单 SELECT w.waybill_no, w.freight_amount, w.actual_arrive_time FROM tms_waybill w LEFT JOIN tms_settlement s ON s.waybill_no w.waybill_no WHERE w.status 60 AND w.actual_arrive_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND s.id IS NULL;这条查询每天凌晨跑一次结果非空就告警。反过来再查一条「结算金额与运单应收金额不一致」的两个方向都覆盖住账基本就平了。真正难处理的是改单——运单签收后客户改重量已结算的单子要做冲红再重算冲红单和原单用同一个结算批次号串起来财务核账时才追得清。本文还有配套的精品资源点击获取
