一文講透阿里商旅賬單系統架構設計實踐

　　阿里商旅作為飛豬旅行旗下面向企業客戶的數字化差旅解決方案產品，依託飛豬旅行機票、酒店供應鏈為企業客戶提供一站式的機票、酒店、火車票、用車等預訂管控及結算票據服務。阿里商旅不僅是集團歡行的供應商，而且近幾年在商業化差旅市場上嶄露頭角，服務了2萬+中大型客戶，43萬+小微企業。

　　 一、背景

　　接手賬單不到1年的時間，就談談我從一個門外漢到賬單系統搭建過程中對於賬單系統架構設計的理解。

　　賬單基於上游供應鏈交易資料，需要上游資料準確可信，建立資金、交易、訂單及賬單核對體系必不可少。

　　其次需要建立賬單資料、票據維度資料，保證對客資料準確，這裡的複雜性在於不同的企業需要提供不同維度的聚合資料、賬單彙總資料、賬單差異明細（商旅火車票票狀態、出差事由等），賬期日要求全部企業系統自動完成對賬出賬，系統需要支援的複雜性、擴充套件性較大，系統的高度複雜性也給對賬出賬的準確、及時造成了極大的困難，很難保證一次出賬率100%和賬單準確率100%。

　　 二、無處不在的賬單

　　對賬、賬單在我們生活中到處可見的，可能自己沒有察覺已經完成了一次對賬過程，生活中對賬場景比比皆是，我們來看看。

　　2.1 生活中的對賬場景

　　舉個例子：早上上班途中，小周看到路邊有個雜糧煎餅，於是過去買個煎餅，老闆指著玻璃上的二維碼說「12塊」。

　　小周掃碼支付12元后，和老闆說「12塊，轉過去啦」，緊接著老闆煎餅遞給小周，聽到自己手機提醒說「支付寶收款：12元。」

　　老闆心裡知道這筆錢到賬了，小周知道「已付12元」，老闆收款確認「已收12元」，這就是生活中的對賬。

　　2.2 對賬的基本形式

　　對賬定義：為了確保同一個事務的資料描述在不同場景，記錄是否一致而進行的一致性比對。　　

　　舉個例子：對於麵館老闆，顧客吃了一碗麵，點菜小票就是原始憑【證】，付了10元錢是【賬】，老闆電腦點菜記錄小票10元是【賬】，老闆賬戶中餘額增加10元是【實物】。

　　賬實對賬：是指我們記錄的賬與實物資產的實際數量進行對賬。

　　賬證對賬：是指將自己的賬本與記賬憑證進行核對。一般記賬憑證由與業務合作的第三方公司提供，在麵館的例子裡，記賬憑證由支付寶提供（交易記錄）。

　　賬賬對賬：是指在上下游相互關聯的賬本之間進行對賬。在整個交易過程中，一般會涉及上下游多套賬，上游比如外部採購、對外銷售，下游比如快遞發貨賬、第三方服務費等。這些賬和總賬之間有非常多的關聯性，所以一般賬賬核對，通常用於確認及修正內部賬之前的資料不一致。

　　 三、賬單系統設計

　　賬單清結算做為核心賬單系統，上游對接了機票、酒店、用車、火車、賠付等多個外部系統，下游又承擔了對接支付、財務、發票系統的職責，不僅“承上啟下”，而且涉及業務複雜。系統內部又有收單、計費、記賬、彙總賬單、付款等多個環節，如圖：　

　　為了賬單系統更加專業化的實現對賬、做好對賬出賬，我對支付、清結算等資金領域進行了體系化的調研和學習，並結合商旅業務自身的特點，總結了一些賬單系統構建的思路方法，並基於該思路進行了較完整的系統化實現，主要從體系化建設出發一起來看看賬單系統架構設計。　　

　　收單：監聽供應鏈訂單訊息，建立賬單清結算系統收單訊息；

　　計費：針對機票、酒店、火車票、用車類目收單訊息，拆分最細粒度費用項（預定/退款、改簽/退款、保險/退保、服務費、賠付等等）費用明細，便於後期賬單資料加工；

　　記賬：按照當前業務規則合併賬單明細，支援to b差異化配置；

　　入賬：核對供應鏈資料、資金資料一致性，配置入賬攔截；

　　出賬：賬期日企業賬單出賬，允許企業自定義賬單出賬，滿足企業差異化、個性化賬單；

　　對賬&還款：企業根據對賬單核對明細，根據賬單進行還款；

　　3.1 收單

　　在賬單收單時，我們可以針對不同的業務接入方提供兩種不同的資料收單模式：

　　1）拉模式：我們主動呼叫獲取資料，並透過資料適配的方式，將資料進行儲存。

　　針對性強，能滿足客戶端的個性化、差異化需求；

　　2）推模式：根據業務需要，接入方將賬單資料資訊主動傳送，資料格式按照賬單標準模型進行適配。

　　及時性好，及時地向賬單推送資料動態資訊，吞吐量大。

　　目前我們採用的是第二種方式，由業務方推送這種模式接入，按照賬單標準模型構造，無需感知業務的資料格式和業務邏輯。

　　3.2 計費&記賬

　　我們需要將各個類目的交易記錄統一定義，按照賬單記賬的標準規則記錄。

　　系統使用計費拆分項為起點，拆分最細粒度費用項（預定/退款、改簽/退款、保險/退保、服務費、賠付等等）費用明細，便於後期賬單資料加工；記賬按照業務規則進行計費項合併。對於冗餘和暫時用不到的欄位可直接設定賬單暫不進行展示。未來擴充套件時，賬單允許企業自定義，按照企業訴求展示賬單欄位和資料展示。

　　（自定義賬單，後文會介紹到）

　　3.3 對賬

　　企業對賬作為企業差旅管理的一個重要環節和基礎能力，賬單準確性是基本的要求。

　　商旅賬單是企業還款、開票核對的重要依據。賬單準確性差，可能會導致商旅在結算、開票環節產生資損，以及影響企業對商旅的專業度的信任，因此要求賬單資訊完整、準確、真實。賬單準確性至關重要，我們需要保證給企業的賬單真實準確，所以系統對賬的設計重要性無庸置疑。

　　以下我們透過對賬的一些手段、方法來看看系統性的解決賬單對賬問題。　　

　　3.3.1 對賬方式

　　對賬方式主要分為三種，單向對賬、雙向對賬和多向對賬。

　　單向對賬：以一方資料為基準進行對賬。比如交易訂單跟資金記錄，以資金結算資料為基準和交易訂單核對，用來發現資金資料為支付成功，訂單資料失敗等異常情況。

　　雙向對賬：以雙方的資料互為基準對賬。既要保證資金資料為成功的，交易記錄也要成功，又要保證交易記錄為成功的，資金資料也要成功。

　　多向對賬：讓更多參與方兩兩對賬，比如交易訂單、資金記錄、賬單等兩兩對賬，保證交易記錄成功的，資金也要成功，賬單資料也正常。

　　顯而易見，多向對賬更能夠全面的發現問題。因此在條件允許的情況下，我們會優先選擇多向對賬。

　　3.3.2 對賬粒度

　　對賬粒度分為兩種，分別是總數對賬和明細對賬。

　　1）總數對賬：選擇一個維度，進行總數級別的對賬。比如賬期賬單消費總數和賬期資金記錄總數對比，總數級別的對賬好處是對賬口徑的設計比較簡單，可以快速實現，不易出錯。缺點就是無法定位問題資料，一旦對賬發現問題。還需要進一步尋找問題資料。

　　2）明細對賬：對雙方的每條資料按照業務規則依次進行比對。它的優點是可以準確定位問題資料。缺點是對賬口徑的設計比較複雜，效率比較低。因為我們需要同時針對漏、重、錯三種錯誤類別設計出較為全面的對賬口徑，同時還要考慮到業務的邊緣場景。稍有不慎，就會影響對賬的準確性。　　

　　因此，推薦的做法應該是以總數對賬為主，首先確認是否存在問題。以明細對賬為輔，對具體問題進行定位。

　　3.3.3 對賬模型

　　我們會提供常用的對賬模型，供不同的對賬場景選取。如果某些特殊場景對賬模型不能覆蓋，也可以採用自定義核對的方式進行對賬。

　　經過總結我們發現，對賬的方式主要就是業務通用規則、多方對比和賬單規則。業務通用規則，比如交易對賬、資金對賬、採銷對賬等多個常用維度。多方比對又可以細分為一對一、多對一、多對多。賬單規則就是常用的計費項核對、記賬核對和允許自定義核對等方式。我們儘可能把這些通用的對賬邏輯模型化，減少重複的開發工作。　　

　　3.3.4 對賬節點

　　資料核對的最後一步就是對賬節點的選擇。可以分為離線對賬和實時對賬。離線對賬主要是透過固定的週期進行對賬，週期可以為Ｔ＋n，也可以透過出賬日對賬，它的好處是適用性較強，基本可以覆蓋所有的對賬場景。系統目前都是針對一定時間之前的訂單進行核對，保證交易、資金、賬單資料準確一致；在出賬日出賬時也會針對企業維度核對當前賬期所有交易記錄資料和賬單資料一致性。對賬節點核對目前有每日核對、賬期日前一天核對、出賬日核對。

　　實時對賬又分為實時對賬和準實時對賬。實時對賬和準實時對賬的區別主要是實時對賬針對結算鏈路中，可以第一時間發現問題資料，對結算流程進行實時監控，而準實時對賬是具有一定的延後，因為交易鏈路存在較長的情況，上下游資料無法做到實時一致，有些場景只能做到最終一致性，這些場景目前只能基於準實時進行對賬，也可以有效的針對業務問題和賬單異常進行告警。

　　3.3.5 差錯處理（平賬）

　　差錯處理主要是針對資料核對過程中發現的異常資料進行處理。我們會建立一個統一結構的差錯記錄，將資料核對發現的問題進行統一儲存。針對自動化平常處理未透過的資料會進行二次核對，避免由於日切等原因造成的問題錯報。

　　對於那些真實存在問題的資料我們會提供兩種解決方式，如果是常見的問題，形成一套標準的解決方案，會把它系統化，採取系統修復&二次核對的方式；如果系統修復異常，那麼會進行系統報警，並進行人工處理，基於此能夠很大程度的降低人工修賬的成本。　　

　　 四、系統設計關鍵點

　　4.1 面臨的挑戰

　　1）賬單準確率問題比如上游訊息丟失、上游資料更新延遲、三費不齊問題等等；

　　2）賬單詳情資料未同步後續沒有機制更新資料，存在部分賬單欄位會在賬單落庫後發生變化，比如酒店訂單狀態，導致離線賬單欄位錯誤，影響出賬資料準確性；

　　3）企業個性化訴求，不同的企業針對賬單要求不一樣，全量賬單欄位提供給企業展示較多，看起來過度冗餘。

　　企業不同的用途以及核對方式對賬單調整、賬單檔案格式、賬單表頭、賬單內容有不同的需求；

　　企業不同的核對方式和核對詳細程度，關注內容不同，對賬單表頭要求不同。

　　4.2 全鏈路系統監控

　　4.2.1 背景

　　賬單準確性存在如下情況：

　　1）存在接受供應鏈訊息丟失的場景，導致訂單未收單未出賬；

　　2）賬單系統存在重複計費、記賬問題，導致訂單無法出賬，影響賬單準確性；

　　3）新老系統切換，針對老系統已經存在預訂單，其他賠付、退款等奇普無法系統化支援出賬。

　　4.2.2 解決手段

　　從賬單全鏈路監控，可以解決因為系統非同步導致鏈路資料丟失，或者資料拆單/合單不一致的場景。

　　增加MAC監控，核對機票未入賬資料、入賬失敗監控及計費記賬金額核對監控；

　　增加pcb監控，實時監控訂單、交易、人費資料；

　　T+1 比對供應鏈訂單表、賬單收單表的增量訂單，按照交易型別分析，對訊息丟失的訂單監控告警，觸發補償任務，自動重試；

　　業務上也會針對離線賬單和出賬資料核對、計費/記賬異常資料核對，保證賬單準確性100%。　　

　　我們分別從類目終態出賬、賬單全鏈路監控考慮，配合賬票一致性校驗來保障出賬和開票鏈路，提供系統平賬能力，針對無法自動平賬的異常資料提供人工修復工具，保證賬單準確性100%。　　

　　4.3 清結算擴充套件-賬單資料表示式引擎

　　提供核心鏈路的擴充套件能力，計費/記賬提供擴充套件能力，可以定義費用項拆分、配置費用記賬規則；針對賬單資料可以配置表示式引擎，針對賬單欄位進行校驗和動態更新。　　

　　4.3.1 背景

　　賬單資料準確性無法保證，導致已出賬單存在欄位明顯錯誤的情況，產生客戶質疑和投訴。

　　賬單記賬沒有針對核心欄位進行攔截校驗，比如入賬時間為空，結算金額為0等，無法保障出賬資料準確；

　　賬單的詳情資料，在計費時持久化後，後續沒有機制更新資料，但是存在部分賬單欄位會在計費後發生變化，比如酒店訂單狀態，導致離線賬單欄位錯誤，影響出賬資料準確性。

　　4.3.2 解決手段

　　建設表示式引擎能力，對背景進行分析，可以提取出共同點：在固定流程中，執行配置化的表示式/指令碼，基於執行結果進行業務處理。

　　舉個例子：針對記賬攔截的場景，配置攔截表示式，執行結果為校驗不透過的具體錯誤資訊，空則透過校驗。

　　基於上述分析，我們需要建設配置化表示式引擎能力，整體能力如下圖：　　

　　4.4 自定義賬單

　　4.4.1 背景

　　對賬單是阿里商旅提供給企業客戶對賬用的，用於企業與阿里商旅核對企業支付的賬單，包含核對本賬期內發生的企業支付明細、本賬期可開票結賬明細、本期及往期待開票結賬明細。不同的企業針對對賬單欄位要求不一樣，全量欄位提供給企業將對較多，看起來過度冗餘。

　　企業不同的用途以及核對方式對賬單調整、賬單檔案格式、賬單表頭、賬單內容有不同的需求；

　　企業不同的核對方式和核對詳細程度，關注內容不同，對賬單表頭要求不同。

　　4.4.2 解決手段

　　提供自定義表頭能力，基於企業自定義表頭和順序，可以實現企業賬單按照配置展示對應的欄位、順序、樣式。　　

　　拆分處理器

　　根據拆分設定，分為excel拆分處理器、sheet頁處理器、行處理器。

　　拆分處理器可以定義拆多少個excel/pdf和每個excel中需要有哪幾個sheet頁，每個sheet頁中每一列的樣式。每一種處理器都有預設的實現方式，且允許自定義擴充套件實現。針對常用的樣式提供了賬單模板，審批單模板等常用的模板，方便快捷接入。　　

　　 五、建設下一代賬單系統

　　商旅賬單系統重構已有半年多時間(業務流程改造和架構升級)，很多技術最佳化也是在業務發展過程中嘗試擴充套件能力，如賬單表示式引擎配置，解決賬單資料準確性問題；如自動化平賬工具，解決賬單三費不齊，賬單不平的異常情況。目前賬單針對賬單核心清結算主要是夯實底層能力，基於計費&記賬進行擴充套件，允許企業自定義賬單，接下來是針對賬票核對能力建設，更多的針對賬票易用效能力進行升級。

　　5.1 業務結果

　　隨著賬單穩定和底層夯實，目前已經實現了系統一次性出賬率100%，賬單準確率100%，賬單工單問題大幅收斂。

　　賬單準確率&一次性出賬率：逐步提升，已達到100%。

　　賬單工單數：逐步收斂，降低了工單投入，提升了人效。　　

　　5.2 未來展望

　　賬單一目瞭然，客戶對賬高效方便，讓客戶的商旅服務更加專業化。

　　建設賬票核對能力：行業獨有的賬票核對功能，完善實物票據與賬單核對、增值稅發票與賬單核對，保證提供給客戶的實物票據真實準確。目前沒有一家在行業內實現此能力，並解決客戶賬票不一致的核對問題；

　　提升賬票易用性：透過易用性在商旅行業內達到服務效率第一，並可將部分能力專利化甚至商業化。