1. 首頁 > 生活百科 >

解析運輸管理系統 快遞單號幾位數

生活百科 快遞單號

運單是指司機完成攬件報單之后到運單被簽收的過程 ， 如果公司業務是一體的 ， 那么運單系統和訂單系統也可以合二為一 。
當司機完成攬件報單之后 ， 運單就開始進入物流/快遞公司的內部運作流程中 。目前 ， 行業中最主要/核心的運作場景可以粗略劃分為：倉儲、干線、末端派送三個部分 。
但坦誠來說 ， 現在大多數的TMS系統主要承載了線下數據的記錄、登記 ， 很少能達到“智慧物流”的效果 。目前運輸管理系統的核心趨勢 ， 是將運作中的流程逐漸智能化 ， 比如說大數據預測等 。
無論公司怎么去實現“智能物流”都需要有物流基礎數據的承載 ， 而運單系統正是承載了一個運單運作流轉中全流程各項基礎數據的系統 。
運單字段
運單信息

  • 運單號：運單號是貫穿整個運輸管理系統的唯一標識 ， 同時也是承運合同的合同編碼 ， 剛開始的運單號為11位數 ， 但因快遞行業的高速發展 ， 部分公司的運單號已經調整為14位數或者更多 。細心的同學可以觀察到運單聯的背面都是密密麻麻的字 ， 上面就是本次寄送快遞的合同 。不過運單號是帶有強業務屬性的編碼 ， 所以技術上一般會存儲運單ID做為系統層級的標識；
  • 尺寸：貨物的長、寬、高；
  • 重量：貨物的重量；
  • 件數：貨物的件數 。在這里分別描述了尺寸、重量、件數這三個字段 ， 如果一個運單只有一個貨物的時候比較容易理解 ， 但在零擔場景會出現了一個運單對應多個貨物 ， 此時就會出現多組尺寸、重量、件數 。所以大家在產品設計時候可以將該業務場景涵蓋在內 。
客戶信息
  • 寄件信息：寄件人姓名、電話、地址是寄送快遞的數據 ， 其中地址可以借助分單服務幫助用戶完成地址的錄入 ， 提升地址規范化水平 ， 同時也減少因為地址解析錯誤而增加的運送成本 。據稱順豐可以將地址解析到18級 ， 但解析準確率與落地情況暫時未知；
  • 收件信息：收件人姓名、電話、地址是派送快遞的數據 ， 這里不進行贅述 。
路由信息
  • 攬件時間：這里的報單時間是指司機在客戶處攬件完畢并進行報單的時間；
  • 交接時間：因不同公司的運作方式不一樣 ， 可能針對業務流程進行劃分并獨立命名 。但因為這里的差異都是基于公司業務需要也進行設定的 ， 但我們在這里統稱為交接時間 。在記錄該項數據時 ， 記錄過程數據和結果數據 。如果只記錄結果數據丟棄過程數據 ， 那么后續進行數據分析時將缺失該部分數據 。所以大家需要根據業務需求制定數據存儲的策略；
  • 簽收時間：運單派送完畢后 ， 收件客戶簽收運單的時間 。在簽收時間這個字段上 ， 因存在拆單派送等多次簽收的場景 。所以大家也需要考慮數據存儲的邏輯 。
財務信息
  • 運單基礎運費：客戶寄送運單的基礎運費 ， 主要基于重量、尺寸進行計算；
  • 運單增值費用：在基礎運費之外 ， 向客戶提供增值費用跟客戶收取的代收貨款費用、回單費用、木架費用、包裝費用等 。
派送信息
派送信息指在末端派送環節派送運單的司機信息 。司機信息可根據業務需求確定展示的規則 ， 如果有客服或銷售人員對接的 ， 那么不需要展示司機信息 ， 提供客服電話即可；但公司本身屬于平臺 ， 又不希望泄露公司信息的可提供虛擬號的方式聯系司機 。
運單流程
【解析運輸管理系統 快遞單號幾位數】正向流程
運單從報單到配送的過程 。這里主要從3PL物流公司通用的功能 ， 部分功能根據實際場景需要略有調整 。
比如在同城業務中就沒有規劃中轉、干線運輸 ， 可能點對點直接派送；在落地配業務中 ， 就只有末端派送環節 。取貨環節由商家準備了好貨物 ， 騎手只需要根據訂單上的地址進行配送即可 。
在全國性物流公司中 ， 一個運單從報單到簽收涉及的環節比上圖的節點還要更多 。
  • 關于報價問題：在C端場景下一般都是提供通用報價 ， 所以提供采用報價模板即可；但在B端客戶時 ， 針對不同的客戶會有不同的報價 ， 可以根據自身需要建立對應的模塊或者報價系統 ， 一般情況下會將報價信息放在CRM系統或財務系統中 ， 此處問題后續另文展開；
  • 物流/快遞行業為了提高支線/干線的裝載率會將一個大件貨物拆分成兩個“包”進行運輸 ， 然后到達目的地城市/中轉場之后再次進行合單 ， 同時在末端派送時也會對同一區域的貨物進行合單派送 。除了國內業務運作中出現的合單 ， 在跨境物流中 ， 承運商也會將零散運單(包裹)打包成一個大單給到第三方 ， 通過對這個大包進行報關、清關能有效降低成本和提效 。合單和拆單邏輯后續另文展開 ， 而跨境物流屬于一個大的命題 ， 跨境物流后續會做為一個系列進行分享；
  • 針對任何一家零擔/快遞等有車承運商、非平臺業務的公司 ， 公司的運輸路由屬于公司底層、核心命脈 。在順豐、德邦支線到干線的線路策略為不考慮裝載率的班次；也有一些公司根據實時貨量去決定線路發車時間的策略 ， 這種方式下需要增加一定的人力成本進行調度 。這個問題的抉擇更多是時效優先抑或是成本優先 ， 沒有絕對的好壞之分；
  • 在取、派調度環節中 ， 一般自營物流會采取人工/自動調度的方式 ， 而在眾包物流或者城配物流中會采取區域派單 ， 人工搶單的方式 。派單和搶單有各自的優劣勢 ， 后續另文展開；
  • 在自營物流中會存在場地管理或倉儲管理的需求 ， 這里主要關注場地貨物吞吐量、吞吐速度、裝卸貨耗時等；
  • 自營物流也同時存在車輛管理的需求 ， 主要關注靜態的車輛保養狀態 ， 動態的車輛關注車輛是否超速、疲勞駕駛等；
  • 路徑規劃一般與司機調度結合在一起 ， 但因為中間涉及到成本、運力、時效等多方面的影響 ， 目前行業中比較成熟的方案當屬阿里的方舟系統 ， 這里牽扯到著名的“旅行商問題” ， 后續另文展開分享我粗淺的理解 。
運單數據交互
本次文章分享承載全流程運單數據的運單系統 ， 所以這里會涉及到多個運單狀態的變更 ， 以及當運單數據達到某個條件的閾值時 ， 是否要通知到某個具體的用戶 。
比如說調度了司機之后是否要進行通知 ， 同時通知了司機之后 ， 司機過了兩個小時還沒有達到客戶處；再比如說一個運單在場地滯留了三天仍舊沒有動靜等諸如此類的場景 。

    推薦閱讀