soa 架構開發（一文詳細講解從接口集成到SOA架構思想）

2023-05-21 20:09:13 1

作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有雲PaaS平臺架構設計經驗，長期從事一線項目實踐

今天這篇文章準備談下從企業集成需求到SOA架構思想，再到ESB集成平臺建設方面的內容。本篇文章儘量從最簡單的問題起源將其，從業務場景需求出發來講解接口集成和SOA架構思想。

看完本篇文章可以對SOA，ESB，接口集成，企業常見端到端協同業務有一個完整了解。

首先要理解一個企業有很多業務流程和活動，比如市場和銷售，供應鏈，財務，生產，研發等，這些業務活動共同來支撐企業從獲取到和的需求，到最終交付產品的整個價值鏈全過程。

為了支撐這個過程往往企業也會劃分為不同的業務部門，比如供應鏈部，財務部，生產部，人力資源部等，各個部門上下遊分工協作來完成對整個企業日常經營活動的全部支撐。

從客戶提出需求，到最終交付產品給客戶，這就是一個閉環的端到端流程，從客戶開始到客戶結束。這個端到端流程往往先是銷售接單，轉計劃部門，計劃部門排計劃，需要原材料採購的把採購計劃下發給採購部門採購，生產產品的原材料都齊備後，排生產計劃發送給生產部門，生產部門進行生產，生產後質量檢查，沒問題後出庫發運到客戶手裡面。

這就是一個完整的端到端流程。（要詳細理解這部分內容可以參考ERP和MRP相關的書籍做詳細了解，也可以參考類似業務價值鏈方面的書籍）。

一個端到端流程要完成可以看到跨越了多個業務部門，上下遊協同才能夠完成。

要支撐企業的業務運轉，企業會建立很多的IT系統，一般企業都是圍繞ERP來建立相應的IT系統，即在ERP基礎上擴展了外部支撐的多個系統，比如CRM，SCM，MES，PLM，WMS等業務系統。同時可以看到一般擴展的業務系統會有一個主管認責的業務部門。比如CRM歸口到市場部，而對於MES歸口到生產部，PLM歸口到產品研發部門。

一個完整的端到端流程，業務部門之間要上下遊協同，那麼在實現信息化後就會變成業務部門歸口管理的業務系統之間要上下遊協同，即業務系統之間需要傳遞信息和數據，否則端到端流程無法協同起來。

比如我們在SCM系統裡面建立的採購訂單，但是採購回來的東西收貨是倉儲部管，對應的系統是WMS系統，而WMS系統收貨的時候必須依據採購訂單進行收貨或確認型號和數量。因此我們就需要將採購訂單信息從SCM系統傳遞到WMS系統。而這種信息傳遞就是通過兩個系統之間的接口來完成的。

即我們常說的，端到端流程往往是連貫的，但是我們建設IT系統的時候往往是分散建立的，那麼這些IT系統之間就必須協同起來滿足完整的流程需要。IT系統之間的協同就通過系統間定義的接口進行，一個接口往往是業務系統雙方共同約定好的技術標準，協議，同時約定好傳輸數據的格式。

SCM採購系統要傳遞一個訂單信息給WMS倉儲管理系統，這個就需要通過接口實現。而接口實現的方法有很多，比如：

以上技術實現不明白的可以先放一邊，要說明的就是接口本身的技術實現方式有很多種，都可以用來實現兩個IT系統之間的接口集成，完成數據傳遞工作。

在上面了解清楚後，我們再來看接口實現的幾個關鍵問題。

查詢接口還是導入接口？

任何涉及到兩個系統之間的接口實現都存在兩種方式，即要麼實現為查詢接口，要麼實現為導入接口。還是以上例子來說，SCM要傳遞一個訂單信息給WMS系統，那麼實現方式有兩種。

這兩種接口實現方式都可以，即如果是在A實現查詢接口，那麼一定就是在B實現導入接口。對於數據源頭方往往是提供查詢接口，對於數據需要方式提供導入接口。

如果是導入接口，那麼SCM系統只要有新訂單產生就可以實時調用接口將數據導入給WMS系統，但是如果是查詢接口，WMS系統並不清楚SCM系統什麼時候產生了新訂單，所以只能定時輪詢調用查詢服務，看是否有新訂單產生。因此對於導入接口往往實時性更好。

接口同步還是接口異步？

對於同步還是異步我們來舉個例子來說明。比如你點了美團外賣，在外賣小哥將外賣送到你公司樓下有兩種處理方法。

對於方法1就是異步，對於方法2就是同步。

即在同步場景下，外賣小哥和你建立連接後，這個連接一直要處於等待狀態，直到你取走外賣為止；但是如果是異步場景，外賣小哥只要將東西放到前臺就返回，不需要和你建立長久等待連接，在這種情況下往往就需要一個傳遞媒介(前臺）。這就是同步和異步最大的區別點。

那同步和異步究竟各有啥優點呢，簡單來說

再簡單來說，就是在同步場景下，A和B兩個業務系統是直接建立了連接同時連接處於等待狀態，直到接收系統接收成功後返回。而對於異常場景下，A和B不直接建立連接，都是和消息中間件建立連接。

實時和非實時

還是上面的場景，如果接口實現為訂單導入，那麼採購系統一有訂單就馬上調用導入接口，就是實時觸發接口。但是如果採購系統是每2小時處理一次，將這2小時新增加的訂單作為一個批次再調用導入接口進行導入，那麼就是定時接口。

對於查詢類服務同步，如果一個查詢人員信息接口服務，業務系統是實時用人員的時候實時查詢接口獲取最新信息，那麼就是實時接口。但是如果是每隔2小時或1天，調用該接口同步增量數據，那麼就是非實時接口。

從點對點集成到總線式集成

集成平臺簡單來說就是將所有業務系統間提供的接口全部統一管理起來的一個平臺，舉例來說：

一個辦公室有5臺電腦，這5臺電腦要連接起來，你可以每臺電腦之間通過網線點度點連接，形成一種網狀的連接結果。你也可以將5臺電腦全部接入到一個Hub交換機上面，通過交換機來實現5臺電腦的連接。同樣有5個業務系統要實現集成，接口可以點對點集成，當然接口也可以全部接入到類似交換機的一個軟體平臺上（集成平臺）上面，通過集成平臺實現類似Hub的總線式集成。

如果有100臺電腦，網站集成的話是n*(n-1)/2，可以看到集成關係越來越複雜，越來越難以管理，但是如果採用Hub集成，那麼集成就變得很容易，以很清晰。

對於業務系統間的接口集成也是同樣的道理。

再舉例來說明，比如有四個人，分別講中文，英語，法語和日語。那麼如果4個人要交流就相對麻煩，每個人都需要懂多門外語，或者自己對語言進行翻譯處理。那麼這個時候我們就可以將四個人全部接入到一個統一的翻譯機，中國人要跟英國人交流的時候，中國人將中文發送給翻譯機，翻譯機轉換為英文後再轉發給英國人。那麼對於四個人間的交流就很順暢了。

集成平臺實現了總線式集成，除了減少了集成點數量外，重點還做以下幾個方面的事情。

以WMS提供訂單導入接口為例，在點對點集成的時候，接口調用為：SCM 調用 WMS接口。在WMS將接入註冊到集成平臺後，集成平臺提供了一個類似的訂單導入接口，過程變化為：

SCM 調用 集成平臺 =》 集成平臺 轉發去調用WMS =》 WMS返回到集成平臺 =>集成平臺返回給SCM

即任何一個接口的調用都涉及到三方，A系統，B系統和集成平臺。

同時從上面這個圖大家還可以看到，所有接口消費的輸入消息和輸出消息全部會在集成平臺管道上進行流轉，也就是說集成平臺可以對消息進行攔截和處理。這也是後續集成平臺對接口進行安全，日誌，協議轉化，數據映射，流量控制等各種管控的基礎。

對於集成平臺的使用，除解決原來業務系統之間點對點集成轉變為網址集成的問題外，究竟還能夠解決哪些問題。在集成平臺實施過程中，最容易碰到的疑問就是對於業務系統間都全部採用了標準的WS服務作為接口標準，那麼還使用集成平臺有什麼樣的必要性？

對於集成平臺的使用，還包括了如下幾個方面的優點。

當然在採用了集成平臺後，也存在一些缺點的地方，比如任何一個接口的集成和實施都涉及到業務系統雙方和集成平臺三方協同才能夠完成。其次就是由於消息需要通過集成平臺中轉，一定會帶來一定的性能損耗。

接口的數據格式和內容

在業務系統之間定義了一個標準的接口後，就需要對接口的數據格式進行定義，對於SOAP WS有標準的WSDL和XSD接口契約文件定義。包括對於Rest接口，現在也有WADL和RAML設計模型。

對於這塊的內容在這裡先不展開，可以自己搜索SOAP WebService和WSDL相關的文章進行學習。

簡單舉例來說，一個郵遞員通知你到哪裡去取你的包裹這個接口，對於WSDL文件中的是說明了取包裹的具體地點和方法名稱；而對於XSD文件則定義了包裹裡面具體裝了哪些東西，是如何裝的。當然XSD文件也可以完全嵌入在WSDL文件裡面，這樣WSDL文件就一併告訴你去兩件事情。

任何數據一定有數據結構，而對於接口傳遞的數據結構本身就是一個樹狀結構，其一定有一個根節點，在根節點下面有1個或多個子節點，同時子節點項目還可以有子子節點。因此你遇到任何一個數據結構就需要搞清楚這個數據本身是分幾層，是1個父親有兩個兒子這種結構（A場景），還是1個父親有1個兒子，1個兒子又掛了1個孫子這種結構（B場景）。這對理解XSD結構和裡面的Collection結構定義相當重要。

舉例來說，我們定義一個客戶信息，一個客戶往往有客戶銀行帳戶和客戶聯繫人，那麼就是上面說的A場景。當然也可以是一個客戶信息，一個客戶聯繫人信息，一個客戶聯繫電話信息，那麼就是上面說的B場景，即三層遞進結構。這個畫個圖示往往更加容易理解，在這裡先省略掉。

為什麼要先定義接口

對軟體工程有初步理解的就容易理解，在軟體工程中有架構設計，而架構設計中一個重要的工作就是劃分組件，並對組件的接口進行設計。

這樣做的目的就是在接口設計好後，各個組件就可以開始並發開發工作，相互不影響，只要大家遵循同樣的接口規範文件，那麼最終開發完成的兩個組件就能夠集成到一起。

接口先行的目的就是大家遵循同樣的標準，那麼後續各個組件就能夠無縫的集成到一起。否則接口實現不一致，那麼後續就無法進行集成，導致功能和接口變更。如下圖所示：

如果把業務系統比做積木的話，只要我們提前定義好了接口的標準(WSDL XSD)文件，那麼三個積木就可以完全無縫的組裝和銜接起來，形成一個完整的整體。

當前集成平臺本身還有接口或數據的轉換能力，那麼就可能如下圖

即ERP和集成平臺間是三角形的接口，但是集成平臺和SCM間是三角矩形接口。SCM和ERP間的接口不標準，也不統一，但是通過集成平臺轉換和適配，很好地將SCM和ERP兩個積木組裝了起來。這也是上面我們說的集成平臺的的另外一個關鍵特點，協議轉換能力和數據轉換能力。

從集成平臺到ESB

前面把集成平臺，接口的概念講清楚了那麼接著講下ESB服務總線。如何簡單來理解ESB服務總線，如果將業務系統間的接口理解為各個點對點連接的鄉間小路的話，那麼ESB服務總線就是將這些小路聚合和連接在一起的信息高速公路，而每次接口傳遞的數據就是在高速公路上飛馳的汽車。

因此簡單來說，ESB總線就是將業務系統間的接口找到，將接口轉變為服務，然後將服務註冊和接入到ESB總線，然後ESB總線將這個接口服務開放給其它業務系統使用，同時對這個接口服務進行統一的管理（安全，日誌，路由等）。

而對於集成平臺本身是一個寬泛的概念，即對於傳統的EAI，數據交換平臺，ESB服務總線都可以納入到集成平臺。從集成的類型來看，文件集成，大數據集成，服務集成（ESB總線）也都可以納入集成平臺的概念。

那麼對於ESB和傳統的EAI和數據交換平臺的區別究竟在哪裡？

因此在ESB實施時候重點是服務的識別，或者說傳統接口如何轉服務。其次才是服務後期的治理和管控。當前在很多網際網路架構下認為ESB平臺偏重，因此也出現了類似OpenAPI平臺，服務網關等更加輕量的SOA總線平臺。去掉了傳統ESB裡面比較重的協議轉換適配，數據映射，服務可視化編排等能力。

集成平臺的實施關鍵內容如何理解？

前面把集成平臺和接口的概念理解清楚後，再來理解ESB實施究竟做哪些關鍵的事情就容易了。對於ESB實施，我們可以參考上面的圖來理解，以ERP提供一個導入訂單接口服務給SCM系統消費來說明。

以上說明步驟都完成後，一個接口的需求，設計，開發和測試工作就全部完成了，也就是說大家遵循同樣的接口標準規範定義，將一個接口完全集成起來了。這也是我們常說的從頂向下的接口設計和開發實施方法。

我們可以來看下SOA本身的定義，即：

SOA是一種架構方法，將傳統的單片式應用打破，分解為離散的、自治的業務服務，利用標準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構建複合的應用從而滿足業務需求的變化。

在面對企業遺留IT系統架構的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統共性的可復用的業務能力；其次就是在構建上層業務流程的時候通過服務組裝和編排來完成。這個思想和中臺思想完全一致。

我們來舉個例子詳細說明SOA架構思想：

我們以註冊一家新公司來舉例，可以看到如果我們要註冊一家新的公司，我們需要和銀行，政府部門中的工商，稅務，質量監督等多個業務部門到交道，最終完成新公司註冊的完整過程。

其一：找到可復用服務

而對於各個業務部門就是我們說的業務組件，我們首先就是要看業務組件本身對外提供了什麼標準的服務能力出來，即先把各個組件可共享，能夠復用的能力識別出來。這些業務組件本身提供很多業務服務能力，在這裡我們只列舉一些和公司註冊相關的能力，如下：

其二：組合和編排服務完成業務

在進行一個新企業的註冊流程中，涉及到核名，辦理驗資報告，領取組織機構代碼證等諸多的業務活動，這些業務活動都需要和上面說的業務部門（業務組件）打交道才能夠完成。

而要完成整個業務流程，就是將上面業務部門暴露的服務能力基於業務活動的流轉進行組裝起來，這樣就完成了一個完整的業務，如下：

可以看到完成整個企業註冊業務流程，本身就是底層的接口服務能力的組合和組裝。

如果註冊流程中增加了一個驗證企業信用要求，那麼我們也很容易在原來的業務流程中增加一個活動節點，該活動節點調用銀行的信用驗證服務能力接口即可。即通過接口服務的靈活組合，組裝，能夠很容易的響應業務流程的變化。

SOA和ESB總線的關係

簡單來說，SOA是一種架構思想，這種架構思想核心是找到服務，組裝編排服務。對於找到的服務我們希望統一進行管理，那麼ESB就是實現服務管理和治理的一個技術平臺。

也就是ESB企業服務總線是實現SOA架構思想的一個關鍵平臺。

如上圖，找到和管理服務你可以藉助ESB服務總線能力來完成，而組裝和編排服務你可以藉助BPM管理軟體來完成。而ESB BPM也是我們常說的實現SOA架構思想的關鍵平臺。

沒有使用ESB能否叫實現SOA架構？

當然可以，只是遺留系統暴露的接口服務沒有進行統一的管控和治理，也就是說對於接口服務的治理水平會比較弱，但是只要你暴露的接口服務是粗粒度和可復用的。同樣可以共享給上層業務系統或應用使用。正如沒有使用BPM，同樣也可以實踐SOA編排思想，只是你需要通過自己寫代碼去編排服務，而不是通過BPM軟體去可視化編排服務。

反之同樣的道理，不用簡單理解使用了ESB就是SOA架構。

比如你使用了ESB，接入了一堆沒有經過標準化，不符合粗粒度特點的接口，這些接口本身混亂也沒有任何服務價值。上層新業務開發也不能使用這些接口服務，那麼這個時候你的ESB就僅僅是一個接口平臺，也沒有實現任何的SOA架構思想。

類似的道理還有我們做微服務也一樣，不要簡單的認為使用了SpringCloud框架就是微服務了，必須要考慮微服務類似輕量交互，鬆耦合等關鍵思想是否實現。

ESB總線需要同時考慮解決集成和解耦兩類問題

由於當前ESB總線產品很多是由原有的EAI和消息中間件產品發展而來，因此更多的強調的是服務或消息集成，而弱化了SOA更加重要的一個能力即服務共享。

而實際上SOA需要解決服務 集成兩方面的問題。

從上面圖可以看到，對於橫向交互協同的接口，更多的是解決跨系統的集成問題，而對於系統中縱向使用的共享能力接口，在共享能力平臺化後，則接口服務可重用，更多的解決就是服務層面的問題。

舉例來說，一個採購系統導採購訂單給ERP系統，這個接口往往並不能復用，但是解決了跨系統集成問題；另外對於MDM主數據提供的供應商查詢接口服務，這個接口服務本身就是數據能力平臺化後提供出的共享數據服務能力，這個服務可以被外圍的SCM，ERP，CMS多個業務系統使用，既解決了系統間集成，更重要的解決了服務重用問題。

你也可以理解，對於服務重用問題的解決，更多都是伴隨著共性能力下沉產生的。然而當前大部分企業將SOA簡單理解為了ESB和集成平臺，更多用SOA去解決集成的問題，而忘記了SOA架構思想的本質仍然是共性業務能力下降，上層應用靈活編排。

前面基本把SOA，集成平臺，ESB，接口這些基本概念講清楚了，今天重點還是進一步解釋涉及到SOA和ESB的時候，一些關鍵技術特性。其中包括了粗粒度，無狀態，位置透明等。

粗粒度

當談到服務的時候，我們談的最多的就是粗粒度，這個概念實際上並不容易理解。

我們還是要舉例來進行說明，比如你去辦理出國籤證，你準備好相關申請材料後就到本地公安局的服務窗口，這個服務窗口就是和你到交道的接口，你把申請資料提交過去，2周後你拿到最終的籤證和結果。可以看到和你打交道的這個服務窗口相對粗，相對簡單，一個輸入，一個簡單的輸出完事。但是要辦理完這個事情，公安局內部則需要經過多個部門，多個崗位處理和審核，最終才能夠完成，即內部的工作是相對細的，但是這個細節你不用關心也不用知道。這就是我們說的接口服務的粗粒度，即粗是相對內部實現的細來說的。

如果我們把兩個業務系統中的資料庫表的每個表都作為一個數據同步接口來實現集成，這種數據接口把細節完全暴露了，反而不符合粗粒度接口的定義。即粗粒度接口服務最強調的就是你要什麼我就給你什麼，你不需要知道還有哪些沒給你，也不需要知道我內部如何實現的。

注意，粗粒度服務可能高可復用，也可能不能復用，粗粒度與高可復用性本身沒有必然關係。比如我們做了一個供應商查詢的數據服務接口，這個接口查詢所有供應商欄位信息，是一個細粒度接口，但是該接口往往更加容易復用。但是我們也可以做一個基於供應商ID返回供應商信用等級的粗粒度接口，但是這個接口就可能只有1個業務系統在業務場景中需要使用。

無狀態

對於WS服務無狀態，也是在理解SOA和服務化中的一個關鍵內容。對於無狀態那麼自然就是基於有狀態和狀態保持來說了，因此首先要說明什麼是要有狀態。

舉個例子來說，我們去遊樂園遊玩，進門的時候要檢查我們的門票，進去了後有很多遊樂設施，當我們再玩裡面的每個遊樂設施的時候，就不再需要檢查我們的門票的，也計算管理員默認我們進了大門後我們就是有效的買了票的遊客。這種場景就要有狀態，即一進門我們是有效遊客這個狀態就一直保持著。當然還有另外一種情況，就是我們驗票進門後，在每玩一個遊樂項目的時候，管理員要重新檢查我們的門票，即管理員並不認我們進大門的時候做的檢查，這個狀態信息帶不過來，那麼這種情況下就有無狀態。

對於服務調用，本身就是典型的無狀態，簡單理解就是你上次調用服務輸入或輸出，產生的任何信息都無法帶入到下次服務調用中。比如你上次調服務傳遞了你的身份，但是你下次調用服務的時候還得傳遞，否則就不認。

正因為服務無狀態，我們在進行集成平臺集群化部署的時候相對來說更容易，不需要做任何的狀態保持。

位置透明和服務代理

前面我們講過服務網關是ESB服務總線最輕量的一個實現，僅僅實現了服務代理和安全等基礎特性。因此要來理解什麼是服務代理能力。

舉個例子來說，順豐快遞送貨到你們公司，你們公司辦公區佔了一棟樓6層，這個時候快遞只需要將貨送到你們前臺就完事，而不需要送到你們實際的辦公位。那麼你們的前臺就起到了服務代理的傳輸中介的作用。即本來順豐快遞應該直接點對點面對你們公司1000個員工辦公位，但是現在很簡單了，快遞只需要面對你們公司的前臺一個人即可。

通過服務代理可以看到，1000個員工內部辦公位的分布，構造這些信息對快遞員是不可見的，是透明的，這就叫做位置透明。即使你內部的辦公位分布出現調整也不影響快遞員送貨。同時可以看到通過服務代理，還有一個好處就是內部的構造和邏輯完全對快遞員是黑盒，快遞員也不能隨意進入到我們內部辦公場所，這也就是保證了我們內部邏輯和結構的安全性。（也可以進一步解釋為何企業在和外部進行接口服務交互的時候，往往要專門設置一個服務網關，並放置在DMZ隔離區的目的）

高內聚和鬆耦合

對於鬆耦合是服務的另外一個關鍵特性，也是我們進行架構設計和組件劃分的一個關鍵特性。鬆耦合往往不是真的接口來說的，而是針對兩個業務組件來說的，只是通過WS服務接口兩個業務組件能夠更好的實現鬆耦合。

當我們在劃分完了業務組件後，如果A和B兩個業務組件之間有100個接口在進行業務和數據交互，那麼這兩個組件就是高度耦合，但是如果兩個組件之間只有3,5個接口在交互，那麼組件之間就是鬆耦合。鬆耦合並不是不耦合，而是指兩個組件之間的耦合程度很低。

鬆耦合後，兩個組件就不一定必須一起設計，開發和部署，而是可以完全分開設計和部署，然後通過接口服務進行業務協同和交互。因此能夠拆分是鬆耦合的一個關鍵特性。

其次，對於鬆耦合的兩個組件，當組件A發生變更，故障或問題的時候，儘量不要影響到組件B。這也是鬆耦合的另外一個關鍵特性。比如A發送數據給B，當B故障的時候也不要影響到A，這就是徹底的鬆耦合。但是這種鬆耦合往往就需要通過消息中間件來完成，通過消息中間件和消息來徹底實現A和B兩個組件的解耦。

今天談下業務，主要還是拿電信行業運營商來舉例說明下，關鍵的業務協同場景。先來說下工程項目的端到端流程，中間可能涉及到的業務系統和關鍵交互接口說明。這裡儘量是把主體流程說清楚，實際的業務比這個當然要複雜的多。

工程項目建設線條

首先當我們要進行工程建設的時候，比如說要在某個省建設5G試點基站和試驗局，那麼首先就要確定投資計劃，並進行項目立項審批和可研。這裡面就涉及到計劃管理系統和項目管理系統，也可能是一個系統。其關鍵就是要形成最終的審批通過的立項項目。後續的所有工作都需要基於立項項目進行。

在項目管理系統中形成了立項項目並審批通過後，項目實際的範圍，具體建設多少個點等，就會涉及到初步的項目WBS分解和項目預算。因此一個完整的項目信息都包括了項目基本信息，項目WBS分解信息和項目預算信息。

項目信息形成後就涉及到實際的後續招標採購工作了，這個應該容易理解。對於招標系統和採購系統在這裡暫且分為兩個系統來說。首先說招標，項目招標最終就是要確定項目如何基於WBS更好的分包，分包後進行相應的招標工作，招標完成後最終形成的就是合格的供應商信息，物料和設備信息，分籤的合同信息。

所以這裡可以看到，招投標完成後往往會形成合格的供應商信息，物料信息，這些信息就需要同步到採購管理系統裡面作為採購用。當然如果有了主數據系統，這些基礎主數據就先在MDM系統裡面形成，然後再分發和同步到採購管理系統裡面。因為採購系統做採購訂單的時候需要選擇供應商和物料。同時我們還需要將招投標結果類信息同步到合同管理系統，合同管理系統根據結果來擬制採購類合同。

這裡再簡單來說，比如5G招標結果已經處理，分為兩個包，華為和中興各中標一個包，其中華為提供交換和傳輸設備給1000臺，中興提供基站和東環設備各1000臺。然後分別跟兩家供應商擬制供貨合同。

前面事情做完後，就開始在採購系統裡面做採購訂單了。比如向華為下達採購訂單。在這裡先講最簡單的就是一個採購訂單，接收點也一個點。

當我們在做採購訂單的時候，我們就需要選擇供應商信息，選擇物料信息，選擇該訂單對應的項目，選擇該訂單對應的合同，選擇該訂單對應的組織，選擇訂單的接收地點等各種基礎信息。可以看到這些基礎信息就需要從招投標，合同，項目管理，ERP等各個業務系統中同步過來。這些是做一張採購訂單的基本條件。當採購訂單下達給供應商後，就涉及到收貨的事情，在這裡將採購系統和物流系統分開來講，即採購系統只管採購訂單，而物流系統來管實物和庫存的管理。

採購訂單生效後，需要將訂單同步給物流系統，否則物流系統不清楚按什麼來驗貨。這是採購和物流系統之間最關鍵的一個接口。對於供應商送貨過來後，物流系統就需要進行接收，送檢和入庫三個關鍵操作。在這裡我們簡化為直接做入庫單入庫來進行說明。

物流系統做入庫單，那麼就需要選是根據哪個採購訂單來進行接收入庫，具體的入庫數量是否和採購訂單數量匹配等。在入庫單做好，物資檢查清楚後進行物資入庫操作。一個物資正式入庫，就涉及到物流系統裡面的庫存操作了，比如入庫需要增加對應的物資庫存數量，出庫需要減少數量等。對應物資正式入庫，有個叫法就叫庫存記帳。意思就是庫房正式籤收入庫，承認收到你的東西併合格了，那麼後續就需要依據這個信息給你進行付款。

對應物流系統一般就要管物資的入庫，出庫，調撥，盤點等相關的操作。因為所有這些操作都會影響到實物庫存的變化，而實際實物庫存的變化都會影響到最終的財務成本核算。而企業上了ERP後，實際的財務成本核算，應收，應付和總帳都在ERP系統裡面。因此對於物流系統操作形成的內容，統一叫做庫存事務處理，需要將這個信息同步到ERP的庫存模塊，作為後續財務成本核算使用。

財務線條基礎

物流系統接收到貨後，後面這個貨根據工程建設進度，就需要出庫發到工程項目現場進行設備的安裝和調試，所有的東西安裝調試完成後，整個試驗局就開通了。最終安裝完成的東西就是客戶的資產，因此需要將你所有採購回來的東西形成一個清單（轉資清單），轉變為客戶的資產。即我花了100萬出去，這裡面就應該有100萬全部轉成了我後續的資產，這樣兩邊的帳才是平的。舉更簡單例子來說，公司來個新員工，公司花5000買了臺電腦，那麼這5000就要轉成固定資產。這樣兩邊的帳才是平的。

工程項目建設如果驗收通過了，那麼就涉及到要給供應商付款，首先我們就需要提交驗收材料和付款申請，啟動給供應商付款的流程。

對於實際的付款就涉及到前端的報帳平臺，我們就需要在報帳平臺中提交一張採購類的報銷單。當然你填寫這種報銷單的時候也需要選擇對應哪個項目，哪個合同，哪個訂單，哪次付款，對應的組織，會計科目，業務大小類等很多基礎信息，這些信息都是從ERP，合同，項目管理，採購系統中同步過來，這些同步全部涉及到接口。

這個時候你在系統裡面建立好報帳單，選擇對應哪個採購訂單，對應的採購接收單，對應的供應商開過來的發票，這三者必須要對應上，才說明完全是一致的，帳實完全相符。這個就叫三單匹配操作。這個完成後走報帳單審批流程，審批通過後，報帳單就會形成應付憑證或叫應付發票（有些付款場景沒有發票）。那麼這個發票信息就需要導入到ERP的應付模塊裡面去。

在報帳平臺建報帳單的時候，還涉及到和預算系統打交道，比如我們下個月究竟要報銷哪些費用，每個類別預計多少錢，我們首先要進行預算申報。預算申報完成，審批通過後生效。那麼我們在提交報帳單的時候就要檢查，我們報銷的費用是否超過了預算，如果超過了，或者沒有預算就不允許提供。對於採購類報帳，你報銷的費用一定不能超過了採購合同的總金額，如果超過就不能報銷，必須要先進行預算調整或合同變更才行。

在應付發票信息導入到ERP後，ERP啟動進一步的業務規則和邏輯檢查，確認這張發票是否可以付款了，如果可以付款就會生成付款指令發給資金系統，資金系統進行付款操作。資金系統在進行付款的時候還需要跟銀行打交道，完成實際的付款過程。