貨票

貨票審核是運輸收入管理的重要組成部分，需要對貨票及雜費收據進行完整校驗，逐票進行徑路、計費、邏輯審核，審核發現差錯經核實後作為收入訂正依據，同時按不同的維度生成平衡表以及貨運方面的財務報表，為進款和票據等業務提供數據共享支持。由於鐵路貨運業務比較複雜，貨票審核是收入管理中重點工作之一，貨票審核程序也是整個收入系統的難點。

貨票審核數據的嚴肅性體現在它是運營分析、決策分析、財務報表的基礎數據，不僅滿足平衡表的需求，還有滿足貨運相關報表的需求，數據的源頭要保證真實可靠，為此需要加強對介面文件管理，被人為修改或者數據不完整不能作為審核共享數據。

審核后數據形成多張報表，表間的邏輯關係要一致，審核的最小單元是財收四。貨票審核庫的數據保留兩年，要保證審核的及時性，減少工作人員等待時間，對於佔用時間長的處理，可以前一天自動處理，工作人員當日查看結果。

審核內容包括以下部分。

1.1 里程審核

根據貨票發站、到站、經由、票種、品名、貨票類型、記事等內容審核總里程、國鐵里程、基金里程、雜費里程以及特價線里程。

1.2 邏輯審核

（1）品名審核。根據貨票運輸類型分為兩種審核情況：一種是對鐵路局補錄的軍運票審核，判斷品名是否為軍運物資、軍運人員、軍運車輛等。另一種是車站上報的普通票審核，如果是未列品名，查找品名代碼是否在品名代碼表中，如果是整車和零擔貨票需要核對品名代碼價號；如果不是未列品名，品名代碼與名稱必須同時滿足品名代碼表某一品名，當票種為整車和零擔貨票時，需要核對該品名的價號。

（2）車輛審核。審核貨票車數與車輛列表的車數是否一致；審核車型是否規範，車型首字元是否為字母；車型標重之和與貨票總標重是否一致；車型允增重相加是否小於計費重量；如果辦理按自輪運轉運輸，貨票計費軸數與實際車輛軸數是否一致。

（3）箱主審核。貨票箱主箱號單位屬性是否與集裝箱實際公司屬性一致；對於一票多箱的貨票，每箱的箱主是否一致。

（4）下浮審核。根據貨票工作日期、發站、發局、發站省市、到站、到局、到站省市、品名、五定班列號、主車型、主箱型、收發貨人驗證下浮條件是否成立，下浮比例是否無誤。

（5）D 型 篷 布審核。D 型篷布號碼是否在已經公布範圍內；篷布使用費核收是否正確。

（6）專用線審核。車站是否有此專用線；取送車費核收是否正確。

（7）發到站審核。根據貨票工作日期，核對發到站是否具備辦理該貨票的能力。

（8）制票版本審核。核對該工作日期的制票版本號和實際發布的版本字典是否一致；通過比較兩個版本，有效監控車站的窗口是否按時升級。

1.3 計費審核

根據貨票發站、到站、收貨人、發貨人、品名、票種、貨票類型、記事等審核貨票費用合計、國鐵運費、特價費用、運雜費等。貨票審核總流程如圖1 所示。

根據用戶的參與情況，貨票審核分為前台處理和後台處理，貨票審核前台工作以B/S 交互方式實現，用戶通過瀏覽器查看審核結果，根據實際情況下發退補款訂正通知、錄入車站退款證明書、取消託運等操作；貨票審核還有一部分重要工作不需要用戶參與，系統自動運行，這一部分工作稱為貨票後台處理。

為了滿足貨票審核的需求，需要設計一些審核字典。對於邏輯審核，需要建立品名字典、車輛字典、箱主字典、下浮字典、D 型篷布字典、專用線字典、站名字典、制票版本字典；對於計費審核，需要建立費率字典、記事字典、線號字典等，並且保留多個版本，根據貨票工作日期系統自動選擇適用計費字典；對於徑路審核，需要建立徑路專用字典，並且保留多個徑路計算版本。

貨票數據在工作庫里保留兩年，如果按照一天12 萬批貨票，全路18 個鐵路局，每個鐵路局每天平均為6 600 張，兩年的數據量為48 萬張，考慮到運輸量較大的鐵路局，可能達到100 萬張。如果在設計時沒有充分考慮百萬級的數據量，資料庫伺服器和訪問客戶端沒有得到優化，伺服器的訪問壓力會很大，查詢速度會隨著數據量增加顯著降低，為了提高貨票審核處理效率，可以做以下的設計：（1）減少訪問資料庫的次數，多在內存中處理。每次訪問資料庫時，抓取多個財收四數據，同時獲得多個財收四對應貨票數據，以減少訪問資料庫的次數。（2）優化訪問資料庫查詢條件。在資料庫設計時對數據關鍵欄位增加索引；儘可能減少查詢條件，在貨票查詢中，利用財收四的信息，拼接貨票關鍵字起止段，減少資料庫比對條件的個數，少用like 或in 等對資料庫的操作。（3）多點部署、併發訪問。系統設計多點部署，通過多個進程來增強數據處理能力，進程間需要有良好的協作關係，如果某一進程發生如系統宕機等異常情況，其它進程要能夠接替該進程完成未處理的事務；多個進程間可以按照策略設定優先順序，優先順序高的系統優先處理。

考慮到貨票數據量大，處理耗時，數據介面文件到達時間不固定等特點，需設計貨票審核自動處理模塊，分別為貨票自動入庫、貨票自動審核、貨票自動拆分模塊。

（1）貨票自動入庫。當接到收入系統專用貨票介面文件后，入庫程序檢查文件是否匹配，查看文件內容是否存在改動，文件內容中票據部分和財收四部分是否一致。當檢查通過後再校驗數據是否重複入庫，按照電報碼、機器號以及結帳日期在記錄表查看是否有入庫記錄，每次入庫前都要對介面文件與記錄表進行核對以確保不重複入庫，如果記錄表中存在，表示此介面文件已經入庫，不需要再次處理，會自動將介面文件移除；介面文件校驗通過後，入庫子進程解析票據文件和財收四文件，將數據入庫，財收四審核標記設置為未審狀態，並寫文件入庫記錄表，發送消息，通知貨票自動審核程序處理該組財收四。

（2）貨票自動審核。貨票自動審核程序接到有待審核的貨票消息后，自動提取收入系統貨票庫中未審核的財收四及對應的貨票，校驗貨票張數與財收四張數以及費用分項與費用合計一致后，逐票進行徑路、計費以及邏輯審核，將審核結果寫入貨票財收四明細表、貨票拆分表、貨票審核差錯表，並將審核標記設置為已經審核狀態，最後通知貨票自動拆分程序進行數據處理。其中貨票審核流程又是自動處理中最複雜環節。

（3）貨票自動拆分。貨票自動拆分程序根據貨票拆分表內容，按照貨運報表財收55-1、財收55-2、財收55-4、財收55-5、財收55-6、財收55-8、財收56-0、財收56-2 的內容以及業務部門規定的報表，計算不同維度的數據，寫入數據表中。為了達到7×24 h 貨票審核自動處理，在設計時要做如下處理：a. 在處理過程中異常情況以文本日誌方式輸出，便於查看和查找原因。b. 實現資料庫中斷重連機制。系統自動探測網路連接以及資料庫連接情況，發生中斷後，能根據連接情況短時間內自動恢復連接，繼續工作。c. 為保持數據字典及時性，系統自動比照數據字典版本，確認有新版本時及時更新，保證審核內容正確性。

（4）貨票定製審核。在貨票自動審核中，存在由於數據字典沒有及時升級導致的錯誤，用戶需要在數據字典升級后通過重新審核來消除該錯誤，所以需要設計一個貨票定製審核程序，指定將某個條件的數據進行重新審核。定製審核處理比自動審核優先順序高，可以對自動審核后的數據進行再次審核，相反則不可以。因為定製審核是由用戶發起的，需要與用戶進行友好交互，在定製審核過程中，定時反饋結果，能讓用戶看見總共有幾組財收四需要審核，目前審核的是第幾組，該組財收四有多少張需要審核的貨票，如果因為任務多需要等待審核，顯示當前等待處理排名，估計等待的時間。

（1）數據部分回滾機制。為了提高處理速度，在貨票審核時，一次性處理多組財收四，在操作過程中存在某組財收四處理異常而其它財收四處理正常的情況，此時系統只回滾有異常的財收四貨票，其它審核成功的貨票提交，達到一個事務內數據部分回滾的處理技術。

（2）多線程處理。貨票審核不僅要審核發送貨票數據而且還要審核雜費數據，為了充分利用系統資源，縮短程序響應時間，改善用戶體驗，系統採用多線程處理機制。

（3）多點部署減少訪問衝突。系統多點部署后，會發生訪問衝突的情況，衝突越多，浪費資源越多，為此系統專門設計了減少訪問衝突的機制，經過試驗證明，該設計起到了良好效果。

2011 年1 月開始，貨票審核子系統分別在北京、濟南、成都、昆明鐵路局進行了不同層次的試點工作，取得了良好效果，試點開始時間不一，最長已經運行了12 個月，沒有出現因為程序漏洞需要重啟服務的情況，貨票審核數據不僅能滿足平衡表、貨運各種報表以及收入系統各子系統數據共享的需要，而且還能為後續統計分析、經營分析和財務報表提供數據支持。