TMS經驗總結

一、主數據

主數據大體可以分為4類：

1、 參與者:客戶（委託單位）、承運商、供應商、經銷商、工廠、裝卸隊、司機、組織架構、員工等；採購物流、銷售物流、零擔、貨代等運輸業務需要維護不同的參與方；無特殊需求的一般統一為公司資料。

2、 位置:行政區域、地址、地址分組、線路/路由；地址會有倉庫、中轉等屬性的標識，用於處理不同業務；地址還會維護工作時間區間；在快遞快運領域還會延伸出車線等內容。

3、 物流設施：按是否可以作為配載容器的分為兩類;可以作為配載容器的設施有貨車、甩掛、集裝箱、火車車皮、周轉箱/托盤、輪船、火車、航班等；不能作為配載容器的設施有車頭、叉車、月台、吊裝等；周轉箱還會有疊放規則。

4、 貨品：貨品類型、貨品、包裝層級、產品組件；包裝層級、產品組件主要用於處理接入訂單的貨物明細非運輸包裝時的換算。

二、訂單

不同行業、不同業務場景的運輸訂單，在結構上會有較大差異，大體分為下面幾類：

1、 訂單+運輸明細；按訂單跟蹤；

2、 訂單+運輸明細+包裝條碼，可以按條碼跟蹤貨物的當前位置或所在車輛；有了條碼可以做裝卸貨掃描以及盤點；

3、 訂單+產品/物料明細+運輸明細，接入的訂單，可能無運輸明細，需要通過產品的包裝層級、產品組件等配置生成運輸明細；這種結構，可以做產品/物料的在途庫存統計，如統計產品/物料的未提貨數量、各段在途數量、中轉倉庫存數量。

4、 訂單+產品/物料明細+運輸明細+包裝條碼，增加條碼作業及跟蹤；

5、 訂單，貨物信息也在訂單頭上；這種結構比較少見，在某大型零擔物流公司的系統里看到過這種結構，在訂單頭上設置了幾種包裝類型，用戶填寫各種包裝數量，如紙箱[ ]箱、木箱[ ]箱……，後台有無生成運輸明細未知。

發貨人給的訂單無貨物條碼，物流公司也會自己列印條碼，但資料庫中並不存儲，比如條碼生成規則為：訂單號+貨物行號+總件數+當前件數，系統根據條碼識別出訂單號。使用這種方案的一般不會出現分量，因為無法滿足條碼跟蹤需求，可以滿足裝卸貨、盤點時通過掃碼來核對的需求。

TMS接入的訂單數據往往需要轉換，最常見的就是兩種：1、根據產品資料中的下單包裝單位、發貨包裝單位，將訂單的產品明細生成運輸明細，如汽車入場物流，下單單位是件，運輸單位是托；2、產品包含組件時，按產品的組件明細生成訂單的運輸明細，如傢具物流，一個電視櫃會包含多個運輸包裝。也做過一個項目，不能按這兩種規則轉換的，下單的單位是升，發貨的單位是瓶，瓶有4升裝和1升裝，這個轉換規則就需要定製了。

有些領域物流還需要提供額外的服務，如傢具，需要上門安裝。

三、配載

TMS的核心就是三個單據：訂單、作業單、運單；對這三個單據，我嘗試過三種設計：

1、 三個單據共用表，單據上有三個標識，是訂單、是作業單、是運單，可以多選。適合於以整車為主的業務。如果一個訂單就是一輛車，訂單和運單就是同一條記錄；如果一個訂單多輛車，一個訂單下生成多個運單；如果訂單是配送訂單，無分段分量時，多個訂單對應到一個運單；如果訂單有分段分量，訂單就拆成多個作業單，運單下可以是訂單，也可以是作業單。

2、 訂單和作業單共用表，運單一張表，適合於以配送為主的業務，絕大多數不存在分段分量，也就沒有必要再存一份作業單的數據了。

3、 訂單、作業單、運單各自獨立的表，絕大多數還是使用這套結構。

總結下配載的作業場景：

1、 調度員在系統中做好配載生成運單，或者導入Excel中的配載結果生成運單，實際能夠按照系統的配載清單（無條碼時只需確定貨物數量，有條碼時還需要指定條碼）裝貨。

2、 調度員先根據訂單單據的地址按線路或區域進行分類，將分類結果通過訂單號的掃碼生成運單。也有司機直接參与的，比如今天有100單要配送，總共三個配送司機，每個司機自己挑選熟悉線路的訂單，客服把結果錄入或掃碼到系統；這種場景做過APP，司機在手機上挑選，挑完後直接生成運單，省掉了錄入工作。

3、 調度員在系統中配載時，無法確定條碼，只能確定貨物數量，需要通過裝貨掃碼來確定本次運輸的具體條碼；有時在裝貨的時候不具備掃碼條件，需要在卸貨的時候來掃碼。

4、 調度員在貨物現場掃碼，配載與裝車同步完成，同時指定下一站點，系統根據掃碼結果自動分段分量生成作業單

5、 調度員開始的時候只能派車，不能夠具體到貨物數量，更不能具體到條碼，需要提貨到中轉倉的時候，通過卸貨掃碼來生成本次的作業單。

一般的TMS都是先分段分量在配載生成運單，這是無法同時滿足上述5種場景的，可以通過設計訂單途徑地庫存表來實現，通過這張表還可以實現中轉站庫存的管理，不需要額外出入庫模塊及報表。

四、跟蹤

跟蹤的需求是確定貨物的當前位置，可以通過對接車載終端或給司機安裝APP來實現。但是，貨物往往會經過多層轉包，這種方案就無法推行，於是就有了一些折中的方案，在訂單單據上列印二維碼，每次中轉的時候要求分包商掃二維碼，提交司機聯繫信息，系統同時採集位置信息；末端簽收的時候也需要掃描二維碼，要求在多少距離內完成簽收操作。

五、異常

這裡的異常是指作業單的發貨與收貨不一致，包含中轉收貨異常、簽收異常，收貨時可能發生：

1、 貨損，貨物損壞或包裝損壞

2、 收貨數量比發貨數量多了

3、 收貨數量比發貨數量少了

4、 中轉時還有可能收到本來發往其他站點的作業單

針對2、3、4三種異常，如果確認問題是上一站點發錯時，一般做法是直接調整作業單，將作業單數量調整為實際的收貨數量，調整的操作相當於重新配載，甚至會影響到其他正常的作業單。

異常處理和配載的設計可以一起考慮，方案是設計訂單途徑地庫存表，可以滿足配載中的5中作業場景，同時也使異常處理更簡單，只需通過調整訂單途徑地的庫存來完成。

六、計費

四種計費類型：

1、 應收計費，一般是對訂單或訂單明細計費

2、 應付計費，一般是對運單、作業單或作業單明細計費

3、 內部交易計費，可以是任務單據，用來子公司間的結算或部門的考核。

4、 成本計費，對某項作業成本的計費，能做到這項的很少，一般都是錄入實際成本，系統按一定規則分攤來計算某個訂單的成本。

計費引擎方案：

1、 計費單據的設計，定義計費所需欄位與實體業務單據欄位的關係，通過計費單據的設計實現對任意單據的計費

2、 計費協議的設計，計費協議就合同，用來定義計費項目，包含計費單據、稅率、合併計費規則等，可能還會涉及到結算重泡比、油價聯動規則。

3、 計費規則的設計，計費規則主要是用來生成費率表的，包含業務因子、計量因子、前提條件、計費公式等信息；在計量因子中可以設定分段規則；

4、 填寫費率表，通過計費規則生成的費率表與實際的價格表樣式基本一致，非常方便維護。

這個方案的優勢是，價格維護簡單，Excel化，計費效率高，通過一次查詢定位到價格。

計費、結算、成本可以做成獨立的產品掛到TMS、WMS、OMS等系統中使用。

七、結算

結算的主要功能是對賬和核銷。

對賬的難點是，不同的結算對象對賬單中的單據不一樣，同一單據要求顯示的欄位也不一樣，還有就是費用要行轉列。可以利用計費引擎中的計費單據來設置對賬單模板，形成一個通用的對賬單解決方案。我做過最複雜的對賬單，包含四個頁簽：公路運輸訂單、鐵路運輸訂單、整租倉庫、臨租倉庫，都可以通過對賬單模板配置出來。通過對賬單模板，還可以實現自動對賬，在對方的Excel對賬單上直接給出對賬結果。

核銷主要是付款核銷與收款核銷，在核銷過程中會涉及預收款、預付款、備用金的管理。

有些領域的結算會複雜些，如液體類運輸，會涉及到揮發、管道留存問題，需要計算實際損耗與合同中規定的損耗進行的差額，計費的過程還需要與WMS結合，結果可能會有額外收益，也可能需要賠償。

八、成本分攤

物流公司通過成本分攤來計算訂單的毛利率，生產企業通過成本分攤來計算單件產品或物料的運輸成本。這就要求分攤是可以多維度的，可以到訂單、運輸明細、產品明細。

成本分攤規則的設計方案：通過配置費用的計費單據與分攤目標單據的關係，設置分攤方式，比如按某欄位的值分攤。然後設定定時器，將所有的應付進行分攤。

有些公司還會要求將公司的費用分攤到訂單，與應付成本的分攤採用相識方案。

九、數據集成

數據格式：xml，json，Excel，中間表

數據交互方式：Web

數據集成也可以做成獨立的產品，通過規則設定，將收到的數據解析為本地的數據對象或者將本地的數據對象生成指定格式的對象。

十、優化

三種優化：路由優化、配載優化、線路優化；三種優化主要是對成本的優化，在快遞快運領域還需要通過路由的優化來避免爆倉。現在做的優化基本都不能滿足客戶的期望。

我只做過一些優化輔助工具的工具，不值一提了。

十一、 SAAS

目前市面上有多款SAAS產品，特別是專線領域，但感覺沒有一家用心的在做TMS SAAS。互聯網企業做了一個簡單的TMS後就開始做物流周邊服務，特別是交易撮合、物流金融，並沒有深入研究不同場景下的差異，可配置型很差，可能是希望用周邊服務來吸引用戶來使用TMS，TMS做不好，能夠有多少用戶呢；傳統軟體公司推出SAAS系統只是為了提高市場佔有率，主要還是依靠克制化來盈利。從前面的十條，已經可以看出做TMS產品的難度。

已經做了10年的TMS，繼續為做好TMS產品努力著。

推薦閱讀：