快递单号几位数(解析运输管理系统)

运单是指司机完成揽件报单之后到运单被签收的过程，如果公司业务是一体的，那么运单系统和订单系统也可以合二为一。

当司机完成揽件报单之后，运单就开始进入物流/快递公司的内部运作流程中。目前，行业中最主要/核心的运作场景可以粗略划分为：仓储、干线、末端派送三个部分。

但坦诚来说，现在大多数的TMS系统主要承载了线下数据的记录、登记，很少能达到“智慧物流”的效果。目前运输管理系统的核心趋势，是将运作中的流程逐渐智能化，比如说大数据预测等。

无论公司怎么去实现“智能物流”都需要有物流基础数据的承载，而运单系统正是承载了一个运单运作流转中全流程各项基础数据的系统。

运单字段

运单信息

• 运单号：运单号是贯穿整个运输管理系统的唯一标识，同时也是承运合同的合同编码，刚开始的运单号为11位数，但因快递行业的高速发展，部分公司的运单号已经调整为14位数或者更多。细心的同学可以观察到运单联的背面都是密密麻麻的字，上面就是本次寄送快递的合同。不过运单号是带有强业务属性的编码，所以技术上一般会存储运单ID做为系统层级的标识；
• 尺寸：货物的长、宽、高；
• 重量：货物的重量；
• 件数：货物的件数。在这里分别描述了尺寸、重量、件数这三个字段，如果一个运单只有一个货物的时候比较容易理解，但在零担场景会出现了一个运单对应多个货物，此时就会出现多组尺寸、重量、件数。所以大家在产品设计时候可以将该业务场景涵盖在内。

客户信息

• 寄件信息：寄件人姓名、电话、地址是寄送快递的数据，其中地址可以借助分单服务帮助用户完成地址的录入，提升地址规范化水平，同时也减少因为地址解析错误而增加的运送成本。据称顺丰可以将地址解析到18级，但解析准确率与落地情况暂时未知；
• 收件信息：收件人姓名、电话、地址是派送快递的数据，这里不进行赘述。

路由信息

• 揽件时间：这里的报单时间是指司机在客户处揽件完毕并进行报单的时间；
• 交接时间：因不同公司的运作方式不一样，可能针对业务流程进行划分并独立命名。但因为这里的差异都是基于公司业务需要也进行设定的，但我们在这里统称为交接时间。在记录该项数据时，记录过程数据和结果数据。如果只记录结果数据丢弃过程数据，那么后续进行数据分析时将缺失该部分数据。所以大家需要根据业务需求制定数据存储的策略；
• 签收时间：运单派送完毕后，收件客户签收运单的时间。在签收时间这个字段上，因存在拆单派送等多次签收的场景。所以大家也需要考虑数据存储的逻辑。

财务信息

• 运单基础运费：客户寄送运单的基础运费，主要基于重量、尺寸进行计算；
• 运单增值费用：在基础运费之外，向客户提供增值费用跟客户收取的代收货款费用、回单费用、木架费用、包装费用等。

派送信息

派送信息指在末端派送环节派送运单的司机信息。司机信息可根据业务需求确定展示的规则，如果有客服或销售人员对接的，那么不需要展示司机信息，提供客服电话即可；但公司本身属于平台，又不希望泄露公司信息的可提供虚拟号的方式联系司机。

运单流程

正向流程

运单从报单到配送的过程。这里主要从3PL物流公司通用的功能，部分功能根据实际场景需要略有调整。

比如在同城业务中就没有规划中转、干线运输，可能点对点直接派送；在落地配业务中，就只有末端派送环节。取货环节由商家准备了好货物，骑手只需要根据订单上的地址进行配送即可。

在全国性物流公司中，一个运单从报单到签收涉及的环节比上图的节点还要更多。

• 关于报价问题：在C端场景下一般都是提供通用报价，所以提供采用报价模板即可；但在B端客户时，针对不同的客户会有不同的报价，可以根据自身需要建立对应的模块或者报价系统，一般情况下会将报价信息放在CRM系统或财务系统中，此处问题后续另文展开；
• 物流/快递行业为了提高支线/干线的装载率会将一个大件货物拆分成两个“包”进行运输，然后到达目的地城市/中转场之后再次进行合单，同时在末端派送时也会对同一区域的货物进行合单派送。除了国内业务运作中出现的合单，在跨境物流中，承运商也会将零散运单(包裹)打包成一个大单给到第三方，通过对这个大包进行报关、清关能有效降低成本和提效。合单和拆单逻辑后续另文展开，而跨境物流属于一个大的命题，跨境物流后续会做为一个系列进行分享；
• 针对任何一家零担/快递等有车承运商、非平台业务的公司，公司的运输路由属于公司底层、核心命脉。在顺丰、德邦支线到干线的线路策略为不考虑装载率的班次；也有一些公司根据实时货量去决定线路发车时间的策略，这种方式下需要增加一定的人力成本进行调度。这个问题的抉择更多是时效优先抑或是成本优先，没有绝对的好坏之分；
• 在取、派调度环节中，一般自营物流会采取人工/自动调度的方式，而在众包物流或者城配物流中会采取区域派单，人工抢单的方式。派单和抢单有各自的优劣势，后续另文展开；
• 在自营物流中会存在场地管理或仓储管理的需求，这里主要关注场地货物吞吐量、吞吐速度、装卸货耗时等；
• 自营物流也同时存在车辆管理的需求，主要关注静态的车辆保养状态，动态的车辆关注车辆是否超速、疲劳驾驶等；
• 路径规划一般与司机调度结合在一起，但因为中间涉及到成本、运力、时效等多方面的影响，目前行业中比较成熟的方案当属阿里的方舟系统，这里牵扯到著名的“旅行商问题”，后续另文展开分享我粗浅的理解。

运单数据交互

本次文章分享承载全流程运单数据的运单系统，所以这里会涉及到多个运单状态的变更，以及当运单数据达到某个条件的阈值时，是否要通知到某个具体的用户。

比如说调度了司机之后是否要进行通知，同时通知了司机之后，司机过了两个小时还没有达到客户处；再比如说一个运单在场地滞留了三天仍旧没有动静等诸如此类的场景。