單據引擎是企業信息化系統中用于自動化處理業務單據的核心組件，通過規則配置實現單據的生成、流轉、轉換及關聯管理。其核心目標是通過靈活的策略配置，減少人工干預，提升業務流程效率和數據一致性。在市面常見的中大型ERP系統都有此功能，比如金蝶云星空的BOTP（單據轉換平臺，詳見：簡略剖析會計引擎BOTP（單據轉換平臺）及原理），用友的TOP與流程引擎在一塊；而SAP則是通過SAP S/4 HANA API實現單據的生成、轉換，如下圖（圖源于SAP官網）：阿里基于強大的技術實力，在其“低代碼平臺”實現了單據引擎功能，將單據引擎抽象成研發能力，其架構如下：單據引擎的應用主要集中在供應鏈與財務這兩大模塊中，主要有：
1、供應鏈模塊轉換
a.采購訂單 → 進貨單 → 采購入庫單
場景：供應商確認采購訂單后，系統自動生成進貨單作為收貨依據。
b.報價單 → 銷售訂單 → 發貨通知單→ 運輸單 → 銷售出庫單
場景：客戶確認訂單后，系統生成發貨通知單，并生成運輸單通知安排物流車輛，分批發貨或直接生成出庫單，觸發庫存扣減。
c.銷售訂單 → 采購單
場景：商貿企業在預銷（以銷定產或采）場景下，當庫存不足時，立馬下采購訂單，通過單據轉換實現信息流轉。
2、財務模塊，包括其他模塊往財務模塊流轉，比如：
a.材料出庫單 → 生產成本憑證
場景：生產領料時，系統自動將材料出庫單數據轉換為生產成本分錄（借：生產成本/原材料，貸：原材料）。
b.采購入庫單 → 應付暫估
場景：物料到貨后生成入庫單，系統暫估應付賬款（借：原材料，貸：應付暫估）。
c.銷售發票 → 應收賬款與成本結轉
場景：開票時生成應收賬款憑證（借：應收賬款，貸：主營業務收入），同時結轉銷售成本（借：主營業務成本，貸：發出商品）。
要注意的是，有些企業是根據銷售出庫單→應收單，因為銷售發票會定期、匯總開具，而不像銷售出庫單必須確認收當月或合并、或一對一流轉至應收單。
單據引擎本質是單據與單據的轉換，實現轉換規則的靈活配置、過程透明、可追溯，將復雜的業務邏輯解耦，
核心能力：支持單據的組合（Join）、合并（Merge）、拆分（Split）、分組（Group）等操作，適應復雜業務場景。
技術本質：基于主從結構（單頭+明細）的數據處理系統，通過規則引擎驅動自動化流程，實現業務單據與業務單據的映射與轉換（單據與憑證的轉換見拆解會計引擎（核心部分），不屬單據引擎范圍）。
單據引擎的設計原理以規則動態化、配置可視化、流程自動化為核心，通過分層架構和元數據驅動實現業務靈活適配。金蝶BOTP更側重單據間轉換（如下推生成各種單據），而中興新云FOL聚焦單據模板自定義與合規控制，兩者均體現了“低代碼/無代碼”的設計理念，以降低技術門檻并快速響應業務變化。
單據引擎通常采用分層架構，分為輸入層、規則引擎層、執行層、輸出層：
1.輸入層：輸入層包括數據源配置、元數據管理、解析規則等，通過對接業務系統的原始單據（如采購訂單、銷售出庫單等），通過元數據解析獲取單據字段、類型及關聯關系。
比如：費控系統的《費用報銷單》（廣告費用），對接到ERP的《應付單》，再生成《付款憑證》；同時采購平臺的《采購入庫單》，也對接ERP的《應付單》，則是生成《暫估應付憑證》；
這一層里，元數據是關鍵點，因為業務永遠是動態變化的，為適應這種動態變化，低成本、動態可配、低代碼的元數據才是解決問題的方向。比如下面這種元數據管理：
2.規則引擎層：核心模塊，包括轉換規則、校驗規則、計算規則的配置。例如：
金蝶BOTP通過KScript腳本定義字段映射、分組策略、選單策略等；
a.源單據與目標單據映射，如源單據《采購訂單》，目標單可勾選《應付單》、《付款申請單》、《采購退料單》、《收料通知單》甚至《銷售訂單》等等；
b.字段映射策略，即源單的A字段，映射到目標單據的B字段；
c.分組策略，配置源單批量下推生成目標單時采用的單據分組依據、分錄合并依據，比如將多個《采購申請單》按同一“組織、供應商”分組（合并）生成一個目標《采購訂單》 ；
d.選單策略，也叫漏斗策略，將源單符合某些條件的篩選出來，生成目標單；
字段映射示例：
中興新云FOL通過可視化界面配置字段類型、校驗條件（如敏感詞檢測、金額合規性）及計算邏輯（如差旅補貼自動計算）。
架構流程（概）圖：
其中：
如【單據編碼】的規則：“關鍵字（'FYBX'）+年月+流水號（跨月重置）”；
如【匯率】：根據源表中【日期】&【幣別】查《匯率表》中對應區間、同幣別的匯率；
【費用類型】：根據源表《費用報銷單》中【報銷項目】查《費用類型mapping》表對應【費用類型編碼】
比如多個《費用報銷單》，按同一【收款人 or 供應商】、【組織】合并生成1個《應付單》單據頭，再用【報銷項目（即轉換后的費用類型】、【費用承擔部門】、【幣別】作匯總，匯總求和字段為【報銷金額（價稅合計）】；
輸出策略，即目標單據是哪個，以及生成目標單據后是直接保存到數據庫，還是要調用接口往下游推送？
模型構建：將上述規則組裝成一個協議或集合，即給一組規則保存一個特定標識或名稱，同樣條件的規則在同一時間只有只有一個生效，比如前面提到的，《費用報銷單》與《采購入庫單》都是生成《應付單》，但二者的后續處理規則是不一樣的，《費用報銷單》生成《應付單》的單據類型是“費用單”，下一步是生成《付款單》；而《采購入庫單》生成《應付單》的單據類型是“暫估單”，是沒有下一步策略的；對比如下：
《采購入庫單》→ 《應付單》；
《費用報銷單》→ 《應付單》→ 《付款單》
另外，如果想做得更完美的同學，可把單據關系設計成可拖拽式的畫布，可以一圖將單據整個鏈條設計概全，一目了然，清晰全面，比如下面這種：
3.執行層：調用腳本解析引擎或規則引擎執行轉換/校驗操作，例如金蝶BOTP通過KScript引擎解析腳本并生成目標單據。包括：
預處理：預處理有可能在接收源單調用，也可能是在生成目標單據時調用，目的是將單據轉換生成所需信息補充完整，確保后續的單據轉換步驟能順利執行。包括數據清洗與標準化（比如前述中定義“【費用類型】”規則）、規則預校驗（比如字段非空性驗證、數據類型匹配（如金額是否為數值型））、上下文環境加載等。
單據生成：根據定義的單據規則生成目標單據，包括模板動態填充、自動化賦值邏輯、分組等。有些場景目標單據不止1個，可能會有多個；比如《物流費用計提單》，從BMS（倉儲物流費用平臺）傳來后，單據引擎根據規則，不僅要生成《計提應付單》，還要生成《暫估（沖銷）應付單》。
校驗：包括系統自動化校驗和人工復核與修正；
?
4.輸出層，功能模塊如下：
在結構設計上，輸出層與執行層既可各自獨立也可合并一個模塊，視業務場景和規則復雜度而定。在實際業務場景中，單據引擎的落地實施可先簡后繁，以對接財務系統為試點，比如費用報銷單，以MVP的形式小規模開發、快速迭代，滿足需求再推廣、升級，鞏固研發成果。
閱讀原文：原文鏈接
該文章在 2025/4/24 9:33:45 編輯過
400 186 1886
