运输调度绕不开的三个老问题
只要企业自己养车送货，或者常年外包车队，下面这三件事几乎每天都在发生：
- 派车靠记忆。 哪辆车空着、哪个司机正在途、谁的车今天限行，全在调度员脑子里。人一忙、请个假，派车就会撞车——同一辆车被派了两趟，或者一趟货临时找不到车。
- 在途是黑箱。 客户电话来问"我的货到哪了"，只能打司机手机。货到了签收没、少没少件，要等回单拿回来才知道，中间隔了好几天，出了问题也说不清是哪一段。
- 运费对不上。 月底结算，翻一沓纸质运单、加油票、过路票，手工汇总，一次对账好几天，还经常和司机/承运商对不上数。
这些问题的共同点是：过程数据没沉淀在系统里。下面这套运输管理的搭法，就是把这些过程一条条数字化——不是要上一套重型 TMS，而是先把"车、人、单、钱"四本账建起来，再让页面和移动端把它们用起来。
第一步：先建三本"底账"
运输的一切记录，最后都要挂到"谁的车、谁开的、哪家承运商"上。所以先把档案建好，后面录运单才有地方引用。
1. 车辆档案
- 车牌号（唯一标识）、车型、核载吨位/方数、所属（自有 / 外协）
- 车辆状态：空闲、在途、维修、停用——状态直接影响能不能被派车
- 补充字段：购置日期、保险到期日、年检到期日（后面用来做到期提醒）
2. 司机档案
- 姓名、手机号、驾驶证号、准驾车型、可驾驶车辆
- 关联到平台的成员账号，这样司机在手机端登录后，只看得到派给自己的运单
3. 承运商档案（外包车队）
- 承运商名称、联系人、结算方式（月结 / 单结）
- 挂靠其下的车辆与司机，自有和外协用同一个"运单"模型，方便统一调度和结算
两个容易被忽略、但很省事的平台能力：
- 下拉选项统一口径：车型、车辆状态、结算方式这类"选来选去就那几项"的字段，用平台的数据字典集中维护。以后要加一个车型，改一处、所有页面同步生效，不会出现"同一车型三四种写法"。
- 跨模块引用：司机、车辆、承运商被运单引用时走平台的引用引擎（一种软外键机制，让一个模块直接引用另一个模块的档案数据源，而不用把姓名车牌再抄一遍）。档案改名，运单里跟着变，不用回头批量改。## 第二步：运单——一次运输的完整记录
运单是这套系统的主线单据。它记录"从哪到哪、运什么、谁运、到没到、多少钱"。
运单从哪来。 通常有两个来源：
- 从销售订单或出库单引用生成，货物明细、件数、重量自动带过来，避免二次录入出错；
- 计划性运输（比如固定线路的调拨）直接新建。
关键字段。
- 起点、终点（可放多个经停点做多点配送）
- 货物明细、件数、重量、方数
- 要求到货时间
- 关联车辆、司机、承运商
- 运费约定方式（按趟 / 按吨公里 / 按时段包干等，只记约定规则，具体金额按企业自己的口径填）
- 回单、签收单等附件
状态流转。 运单建议做成一条明确的状态线，每一步都有出口：
待调度 → 已派车 → 在途 → 已到达 → 已签收
任何环节可转 → 异常（货物破损、延误、拒收等），并记录异常原因
状态线是后面所有看板和统计的基础：调度看的是"待调度"，客户服务看的是"在途"，财务看的是"已签收"。状态怎么变、谁能改，可以用平台的工作流（一种把"谁在什么条件下做什么"配置化的机制）来约束，比如"改运费金额需主管确认"。
第三步：调度台与在途看板——把页面用起来
数据建好只是地基，调度员每天面对的是两个页面。
调度看板（排车）
- 左边是待调度运单池，按要求到货时间排序；
- 右边是可调度车辆池，只显示状态为空闲的车，司机空闲情况一目了然；
- 支持一趟车挂多张运单：同一辆车顺路带两三个送货点，拼车、多点配送都能表达；
- 派车动作把运单状态从"待调度"推到"已派车"，同时把车辆状态改成"在途"。
在途看板（盯货）
- 一张表列出所有在途车辆，按预计到货时间排序，超时的行高亮；
- 点开某辆车，能看到它当前载的运单、走的线路、上一节点的更新时间；
- 到货后由司机在移动端确认，看板实时更新。
车辆状态看板
- 一眼看清多少车在途、多少车空闲、多少车在维修——排产排运力时不用再去问调度员。
第四步：费用与对账——把运费算清楚
运输的账，主要是两类：应付给司机/承运商的运费，和运输过程中的杂费。
- 杂费登记：加油费、过路桥费、装卸费、临时停车费等，按车次或运单归集，附上票据照片；
- 运费对账：按承运商、车辆、月份汇总本期应付运费，生成对账单，导出后交财务；
- 和收付款的衔接：对账结果可以作为财务收付款台账的引用来源，把"运输花了多少"接进企业的资金账，而不是散落在 Excel 里。
需要提醒的是：计价规则各家不同，系统里先把"计价方式"作为字段和字典固化下来，把每一次的金额如实登记，统计口径由企业自己定——系统负责"不漏记、可汇总、可追溯"，不替企业定价格。## 第五步：移动端——司机在路上，调度在办公室
运输是典型的"一半在电脑前、一半在路上"的业务。平台的一个省心之处是：在 PC 上用 AI 构建器搭好的模块，会自动出现在移动端，不需要为手机另做一套。
司机端（手机）该有的：
- 登录后只看到派给自己的运单，一条条按时间排好；
- 一键更新在途节点：出发、途中、到达、异常，每步可拍照上传；
- 到货签收：收件人签字或货物照片直接拍上传，回单照片一并提交；
- 异常上报：延误、破损、拒收，选原因、写备注、发照片，办公室立刻能看到。
调度/管理端（手机或电脑）：
- 手机上随时查在途状态，不用回办公室开电脑；
- 异常上报触发通知推送，相关负责人第一时间收到；
- 需要审批的（如临时加价、改线路）走移动端审批，不压单。
驱动的关键是权限：司机、调度员、财务看到的数据范围不一样。平台的角色与权限体系可以把"司机只能看自己的单、财务能看金额不能派车"这类规则配出来。
上线前，这几件事先查一遍
模块搭完别急着用，按下面清单过一遍，能省掉上线后的很多返工：
- 状态线是否闭环：每个状态都有下一跳吗？异常状态有没有出口，能不能回到正常流程？
- 引用关系对不对：运单里的车辆、司机、承运商是不是走了引用，档案改了运单会不会跟着变？
- 字典是否统一：车型、车辆状态、结算方式这些下拉，是不是都从数据字典取，没有手输的口子？
- 权限是否隔离：用几个不同角色的账号各登录一次，确认司机看不到别人的单、看得到的地方不会误操作。
- 移动端是否挂好菜单：司机角色能不能在手机上找到"我的运单"入口，页面在手机上显示是否完整。
- 发布预检：用平台的模块预检功能跑一遍，把配置和数据问题在上线前挑出来。
- 到期提醒是否跑通：保险、年检这类日期，用平台的定时任务（按 Cron 规则定期执行的动作）在到期前自动生成提醒——先手动触发一次看效果。
之后可以怎么延伸
这套骨架搭好，运输业务的很多延伸需求都能顺势长出来：
- 车队管理：把车辆维保记录、油耗、年检保险都挂到车辆档案上，做成完整的车辆全生命周期台账；
- 承运商评级：按准点率、异常率、对账准确度给外协车队打分，作为下次派单参考；
- 运力分析报表：按线路、车辆统计趟次与成本，看哪条线路该优化、哪台车利用率低；
- 和仓储衔接：运单与出入库单打通，出库即生成运单，到货即触发入库，减少一次录入。
运输管理的价值不在"功能多"，而在过程数据第一次被完整地记下来：车在哪、货到没到、钱花了多少，随时查得到。从三本底账和一张运单开始，先用起来，再按业务需要往上加——这正是用 AI 构建器搭业务模块的节奏。