做运输管理时，很多人最先关心的是：
车现在到哪里了？
司机出发以后。
车辆有没有到仓库？
是不是已经进入港区？
距离目的地还有多远？
所以实时车辆定位，是一个非常直接的运输管理需求。
但真正遇到异常之后，企业往往会继续问另外一些问题：
这辆车之前到底怎么走的？
中间有没有停过？
停了几次？
这一趟实际跑了多少公里？
客户说车辆晚到了，问题到底发生在哪一段？
这时候，只知道车辆“现在在哪里”，其实已经不够了。
还需要把过去一段时间的运输过程重新还原出来。
所以在车辆实时定位之外，立刻云进一步增加了：
车辆轨迹查询
通过输入黄牌车辆的：
车牌号
开始时间
截止时间
系统可以查询车辆在指定时间区间内的历史行驶轨迹，并进一步统计：
- 总计里程
- 停车次数
- 行驶路线等相关数据
让车辆定位从：
“现在在哪里”
进一步延伸到：
“这段时间是怎么走过来的”。
实时定位解决“现在”，车辆轨迹解决“过去”
这两个功能看起来很接近。
但实际解决的问题并不一样。
实时车辆定位
回答的是：
这辆车现在在哪里？
适合：
客户临时问车辆位置。
操作人员查看当前运输状态。
判断车辆是不是已经接近目的地。
车辆轨迹查询
回答的是：
这辆车在过去某一段时间里是怎么运行的？
适合：
运输完成以后复盘。
异常延误排查。
司机行程核查。
停车情况分析。
里程统计。
所以车辆轨迹并不是简单地把实时定位“多显示几个点”。
它更重要的价值是：
把一段运输过程重新还原出来。
场景一：客户问“为什么今天晚到了？”
这是车辆轨迹最典型的应用场景之一。
比如一票货物原本预计：
下午 2 点到仓库。
最后实际到达时间却是：
下午 5 点。
客户可能会问：
为什么晚了 3 个小时？
如果只看现在的位置。
车辆已经到仓库了。
已经无法判断之前发生了什么。
这时候，可以直接根据：
车牌号。
开始时间。
截止时间。
查询这段时间内的车辆历史轨迹。
系统将车辆的行驶路线重新展示出来。
再结合停车次数等数据，就可以进一步判断：
车辆是不是途中长时间停留。
是否存在绕行。
哪一段运输时间明显异常。
这样处理客户问题时，就不再只能依赖：
“司机说路上堵车了。”
而是多了一份实际轨迹数据作为参考。
场景二：想知道车辆这一趟到底跑了多少公里
运输业务里，里程本身也是一个非常重要的数据。
比如企业想核查：
这一趟提货实际行驶了多少公里。
运输路线是否合理。
司机申报的里程与实际行驶情况是否存在明显差异。
过去如果没有轨迹数据，通常只能依赖：
司机填报。
地图大概测算。
或者凭经验判断。
车辆轨迹查询之后，系统可以根据指定时间段内的车辆行驶信息，进一步统计：
总计里程。
这样车辆管理就不再只是一个地图上的位置点。
而开始有了可以用于分析的运输数据。
场景三：一趟运输，中途到底停了几次？
有时候车辆并没有明显偏离路线。
但运输时间就是比正常情况长很多。
问题可能并不在：
走错路。
而是在：
停车。
例如：
途中等待。
临时休息。
堵车长时间停留。
进入某个场站后等待装卸。
如果只看起点和终点，很难判断这些情况。
车辆轨迹可以进一步统计：
停车次数。
结合实际轨迹查看，可以帮助企业了解：
这辆车在运输过程中是否存在较多停留。
哪些停留属于正常业务节点。
哪些停留值得进一步核实。
对于一些时效要求比较高的运输业务，这类数据会比单纯的“最终到达时间”更有参考价值。
订单里的车辆，也可以直接查轨迹
车辆轨迹并不是只能在单独的车辆定位页面使用。
如果一辆车已经关联到具体订单，也可以直接从订单业务场景进入。
例如订单已经维护：
运输明细。
运单。
车牌号。
那么操作人员在处理这票订单时，可以直接通过车辆定位继续查看：
车辆轨迹。
这样查询过程仍然围绕当前订单展开。
不需要先记住车牌号，再退出订单去另外一个功能里重新查一遍。
对于日常操作来说，这种方式会更加顺手。
从“车辆位置”变成“运输过程”
如果只有实时定位，系统记录的其实主要是一个：
位置。
例如：
当前车辆位于苏州工业园区。
但有了车辆轨迹以后，企业看到的就开始变成一个：
运输过程。
比如：
上午 8:20 出发。
↓
沿指定路线行驶。
↓
途中出现一次停车。
↓
继续前往仓库。
↓
下午到达目的地。
↓
本次累计行驶 XX 公里。
管理者看到的不再只是地图上的一个点。
而是一段更加完整的运输过程。
这对于：
运输追溯、异常复盘、行程核查
会更加有价值。
特别适合这些业务场景
车辆轨迹功能尤其适合一些需要关注陆运过程的国际物流企业。
例如：
港前运输
车辆从客户工厂提货，到仓库、堆场或者港区。
可以查询实际运输轨迹。
报关运输
货物从装货点进入监管场所。
发生延误时，可以辅助核查车辆运行情况。
中短途运输
企业需要关注：
实际里程。
途中停车。
运输时效。
轨迹数据可以提供进一步参考。
客户异常查询
客户提出：
为什么昨天那票车那么晚？
可以直接查询对应时间段的历史轨迹进行复盘。
查询时，只需要三个核心条件
车辆轨迹查询本身并不复杂。
核心就是三个信息：
车牌号
告诉系统要查哪一辆车。
开始时间
从什么时候开始看。
截止时间
看到什么时候结束。
确定时间范围之后，系统就可以根据车辆定位数据源返回的信息，展示这一时间段内的车辆轨迹和相关统计结果。
所以在实际使用时，时间范围越明确，查询结果也越容易与具体业务对应起来。
实时定位和轨迹查询，是两种不同的查询
这里需要特别注意一个容易误解的地方。
虽然：
实时定位
和：
车辆轨迹
都属于车辆定位相关能力。
但两者属于独立查询。
因此费用也是：
分别计算。
例如：
同一个黄牌车辆。
先查了一次实时位置。
之后又查询历史轨迹。
系统会分别计算两次查询费用。
实时定位怎么计费？
实时定位查询：
一次扣费 1 票。
但对于同一个车牌号：
同一天内查询 N 次，也只扣费 1 票。
也就是说，如果当天已经查询过这辆车的实时位置，后续当天再次查询，不会因为反复刷新而不断重复扣费。
车辆轨迹怎么计费？
历史轨迹的计费方式与实时定位不同。
车辆轨迹是按照：
查询涉及的天数
进行计费。
例如：
一个车牌号查询 1 天的车辆轨迹：
扣费 1 票。
如果查询连续 2 天：
扣费 2 票。
以此类推。
所以如果只是为了核查某一次具体运输，建议根据实际业务时间设置合理的开始时间和截止时间。
不需要为了查询一次短途运输，直接选择很长的时间范围。
为什么车辆轨迹不是“实时定位的附属功能”？
因为两者服务的是运输管理的不同阶段。
运输正在进行时：
实时定位更重要。
企业关心：
现在在哪里。
还有多久到。
有没有到指定区域。
运输已经结束，或者发生异常以后：
历史轨迹更重要。
企业关心：
走过哪里。
停过几次。
跑了多少公里。
异常发生在哪个时间段。
所以车辆轨迹真正补齐的是：
运输发生之后的追溯能力。
从“问司机”，到“先看看轨迹”
以前遇到运输异常。
很多企业第一反应是：
打电话问一下司机。
这当然仍然是必要的沟通方式。
但问题是：
司机描述是一种人工反馈。
轨迹数据则可以提供另外一个参考维度。
以后再遇到：
车辆延误。
路线异常。
长时间停留。
客户质疑到达时间。
可以先在立刻云中查询：
实际车辆轨迹。
再结合司机反馈和业务情况判断。
这会比单纯依赖口头描述更加清晰。
让运输管理不仅看结果，也能回看过程
很多货代系统过去更关注的是：
订单最终有没有完成。
货物有没有到。
运输状态是什么。
但随着客户对过程透明度要求越来越高，企业也开始需要知道：
中间到底发生了什么。
车辆轨迹查询就是把这部分过程信息进一步补充进来。
通过：
车牌号 + 时间范围
可以重新查看车辆历史行驶路线。
同时得到：
总计里程 + 停车次数等统计数据。
让原本只在运输过程中短暂存在的位置数据，变成后续还能继续查询和复盘的信息。
对于需要管理大量陆运车辆、提货任务和运输节点的国际物流企业来说，这类能力最终解决的其实不是：
“地图上多了一条线”。
而是：
运输完成以后，企业仍然有办法回答——这辆车当时到底是怎么走的。
最后千万记得，查询黄牌车定位需要获取运输公司或司机的授权。
车辆轨迹功能的详细操作方法可查看：
《V79.立刻云操作指南：车辆轨迹功能》