全文共7437個字，分概述、三點認知（原理）、業務到會計引擎、會計引擎設計四部分業財一體化是一個非常大的主題，我想可能需要至少20篇萬字長文才能夠詳盡其所以然；不過內容再多只要一點一點的切入，一塊一塊的展開，總可以從入門逐漸到精通
一個企業的存在需要通過采銷的經營活動不斷獲取營收，采購原材料或者服務，經過生產加工成商品再賣出去獲取利潤；在整個業務發展過程中存在著非常多的業務，例如采購原材料，原材料入庫，加工生產，商品入庫，銷售，營銷等等不同的業務需要不同的人員參與管理，同樣不同的業務有不同的“業務流程”，不同的業務流程存在著不同的業務環節......一個企業經營的好壞，賺了多少，賠了多少，需要財務數據進行反映，同樣企業的全部業務都需要進行財務數據的記錄同樣業務流程中也都有財務參與的影子，例如營銷的預算需要財務進行審批所以，業務跟財務是緊密聯系在一起的，相互關聯、相互依賴、互為支撐，業務流程中包含了財務的流程，同樣財務的數據來源于業務，誰也離不開誰業財一體化就是業務跟財務的融合，業務和財務本身互為聯系，但是二者的這種聯系卻有多種形態，比如在數字化盛行之前，業務跟財務通過線下聯系，可能業務和財務都是線下發生的，線下下單，線下發貨，紙質的入庫單、采購單；財務也是紙質的賬簿、紙質憑證......慢慢隨著互聯網的發展，業務逐漸線上化，例如電子商務、電子支付盛行以后，基本采銷都可以實現線上進行，包括入庫、發貨等都可以實現線上數據傳輸，不再依賴線下的各類紙質單據同樣財務也實現線上化，軟件化，像用友、金蝶、SAP等軟件中的財務軟件部分可以很好的對財務業務進行數據化管理，電子憑證、電子賬簿等一個企業的線上化發展往往是先從局部進行，然后逐漸實現整體線上化，這跟一個企業中的不同部分的重要程度不同有一定關系，企業的業務實現了線上化，財務也實現了軟件化，但是業務跟財務之間的聯系對于大部分企業來說是線下進行的例如我們出差報銷可能需要填寫紙質的報銷單，貼紙質的發票，然后領導簽字，給到財務部門......業務經營數據每月由各業務系統出具報表給到財務，財務根據數據報表編寫對應的會計憑證，每月財務再根據會計數據生成相應的報表提供給高層做決策業務跟財務的線下聯結一般不會對業務的發展造成什么影響，不會影響到業務的銷量和利潤，但隨著業務的擴大、業務種類的增加、業務流程加長，業務跟財務的這種聯系逐漸開始變得繁瑣和臃腫，在內部效率上逐漸露出弊端，同樣財務數據披露的時效性開始制約業務的發展，經營效果披露的時效性矛盾越來越明顯同樣，財務對業務的支撐效果要求越來越高，預算計劃趕快審批，經營效果分析趕快披露，結算款趕快支付等等矛盾一旦升級到了這個地步，一體化就體現出他的意義和價值，在業務活動和財務活動之間構建一道橋梁，可以使業務跟財務之間的重要聯系實現線上化鏈接，極大的提高業務跟財務之間的溝通效率，財務可以從線上參與業務支撐，快速審批、快速評估、快速付款；同樣業務數據可以通過線上直接觸達財務，甚至業務發生以后可以立刻觸達財務，經過財務活動加工處理生成財務數據以及報表，快速提供經營決策依據，對高層高時效的提供財務報表通過上面的分析知道，業財一體的關鍵是構建“業務活動跟財務活動之間的線上化鏈接”，財務可以通過線上支撐業務，業務活動數據可以通過線上高時效觸達財務；從業務數據到財務數據，除了需要運營系統的支撐還需要會計引擎的實現，會計引擎將業務數據翻譯加工成財務數據提交給財務系統各類業務往往是分散的，不同的業務線，不同的業務類型，不同的業務環節所產生的的數據或者說業務單據分散在各處，同樣對于財務來說需要的業務數據跟業務本身需要的數據存在差異，例如采購訂單，業務層面需要的數據與財務需要存在差異，財務可能除了采購單基本信息之外還需要合同信息、發票信息等所以，需要一個業務的數據中心，其中采集、匯集、整理、加工全部的業務數據，以滿足財務對業務數據的需求，這就是業務臺賬，業務的發生需要將對應的采購單、訂單、入庫單、發票、報銷單、合同、預算等數據同步這個數據中心業務有業務的運營管理平臺，財務有財務的運營管理工具，為了實現業財一體構建共同的的運營鏈接，可以構建一個共享運營平臺，通過共享運營歸集分散的雜亂的業務流程，從而制定統一的流程和規范，由統一的財務制度和理念進行支撐管理在該運營平臺財務可以更好的為業務服務，進行統一的業務審核、資金管理、收款付款、憑證制定等，從而實現財務流程的線上化，全集團業務的流程統一化、標準化一個企業的業務是非常繁多的，每一類的業務環節有很多，所以，業財融合是個逐步的過程，先實現重要業務中的重要流程的核心環節的線上化鏈接，然后循序漸進，更多的環節加入進來，更多的流程實現自動化鏈接對整個企業的全部業務進行抽象，例如采購業務、銷售業務、入庫業務、發貨業務、工資發放業務、供應商選擇業務、內部員工優惠審批、業務報賬等等，搞清楚了這些業務分類，后續進行各個突破不同業務的流程進行抽象規范，以上的不同業務都具備對應的流程，例如采購業務就需要挑選供應商、對供應商進行評估、采購合同制定、預算制定、發票、貨款支付等等，其中也需要不同人員進行審批不同流程的環節劃分，就像上述的采購流程中就有很多的環節，比如其中的貨款支付環節就可以實現線上審核、線上支付，通過建立銀企直聯體系實現線上操作付款業務本身的線上化是業務一體化的前提，如果業務的銷售、獎懲、計費都沒有實現線上化，與庫房也沒有實現入庫、發貨的數據鏈接，各類數據沒有得到統一，那實現業財鏈接也就是天方夜談下面這張圖是一個企業在業務端的財稅模塊，主要是面向銷售環節中的商家結算、業務記賬、商家及用戶稅務和發票管理、商家訂單結算款支付的處理平臺其中的記賬數據來自各業務線的不同業務，商品或者服務銷售的清分計費、記賬、以及結算付款，這部分業務在客戶賬務模塊和結算模塊實現，通過付款類通道進行結算款的支付稅務模塊實現不同稅種的配置、計算、稅費代扣、稅務申報等職能，報稅通過相關報稅通道實現發票模塊是基于稅務數據或者銷售數據等進行的發票數據采集、封裝生成開票所需要的全部數據以及進行開票申請，并對開具的發票進行存儲和管理我提煉出的這三點可以高度概括業財一體化，打開業財一體的大門業務是非標準化，不同的領域、不同的公司、不同的部門、不同的系統都各不相同財務是標準化，有嚴格的會計準則和法律法規，這也是為什么有全球通用及國內主流的會計軟件的原因大部分企業的業務是業務，財務是財務，業務按照財務要求提供數據報表完成記賬而業財一體，讓業務和財務在數據層打通了，怎樣將非標的業務與標準的財務連接起來呢？這就是業財一體的鏈接模型，從各種形狀的口轉換成財務的方口而要完整的把握業財一體，或者說是去接手一個業財一體的項目，還應該再增加2點認識，構成5點模型不同行業，不同公司，不同部門和人員目的不同，要想做好業財一體順利推進，那要了解各個角色的需求是什么
當然，這是個決定要做就困難重重的項目，每個部門每個人都有自己的小九九，業務要投入資源配合你，財務害怕你優化掉了他們的飯碗......
那么，要開始做業財一體，怎么下手，如何落地，這里給大家一個參考路徑既然要做業財一體，那么財務那一頭至關重要，它就像一個水庫
我業務的水要灌進去，是打通一個管道直聯水庫，還是建立一個車隊，長途運輸目前市面上有成熟的業財一體化解決方案，企業可以選擇將訂單、支付、報銷、合同等業務及數據直接對接解決方案的相應模塊，灌入數據，自動業財一體當然，每一個解決方案模塊都有成本，全局采購不是一般企業可以承受得了的，例如采購模塊、生產計劃、車間管理、財務管理、倉儲管理、銷售管理、人力資源管理等直接將業務數據轉換成財務憑證數據，對接財務模塊，業務部分保持自研系統
這就是在中間的轉換環節，做好數據轉換，也就是會計引擎要想實現業務和財務的高度融合，實現數據打通，提高業務和財務的雙向互動，建立起業財鏈接，那就必須搞清楚會計引擎了
先看一個實例，在沒有實現業財一體之前，我是怎么跟財務合作的，每月底會收到財務的結賬通知郵件，郵件中包含了200多張數據報表需求，按部門，按業務，按系統提供，每張報表后有提供負責人其中有一張報表叫“薪資表”，本質上是商家的收入結算表，是全部商家在A業務線的全部收益明細，最后計算本月應付其最終收入，這張表有上百個字段，記錄了每一個個人商家接單數量、單價、總價、優惠補貼、獎懲等一系列費用明細匯總次月初由運營人員從系統中導出該數據報表，進行數據核對以及加工處理，然后提供給財務，財務進行內部的應付款審核流程，完成全部審批以后，提供給資金部門進行批量付款，以此整個結算付款流程才算結束同樣，這樣報表也是財務生成會計憑證的原始業務數據依據，報表中的訂單收入、營銷補貼、獎金罰款等涉及到幾十項費用，也就會生成及張會計憑證突然有一天，財務說金蝶有憑證接口，你們到了月底能不能實現自動生成憑證，我們審批通過以后直接提交給金蝶系統，這樣就省掉了線下大量的數據處理、管理、審批流程了這個需求里就體現了幾個關鍵的要素和問題：哪些業務數據、哪些會計憑證可以實現自動化、業務在哪里轉換成會計憑證、什么時候轉換、轉換成啥科目、哪些業務數據轉換成憑證的什么字段、怎么查看轉換后的憑證查看、何時推送金蝶生成正式憑證等一系列問題需要思考這就是會計引擎要解決的問題，其做為業務和財務的連接器，實現業務數據向會計數據的轉變，實現原始憑證向會計憑證的轉變會計引擎就是業務數據向財務數據轉換的翻譯器，通過一系列的轉換規則和業財數據映射關系將不同的業務數據轉換成預制會計憑證不同的企業往往有不同的業務流程，比如純互聯網企業與加工制造企業在業務流程上有特別大的差異，相同的企業在相同事務上的業務流程也有巨大的差異，梳理清楚企業的業務分類以及業務流程非常重要，并且要弄清楚業務流程與財務流程的融合之處，以及流程中所產生的會計憑證是什么但無論什么樣的企業，在大的流程分類上具有相似性，比如采購付款、銷售收款、費用報銷、員工薪酬、固定資產等流程企業需要向上游供應商采購原材料或者服務，通過內部加工生產成商品或者服務產品銷售給終端客戶獲取利潤；而采購的過程就需要向供應商進行付款，該過程是收獲了原材料、支付貨款的過程過程中不僅要與供應商簽訂采購合同、還需進行采購發票的處理以及支付付款處理，所以產生了采購訂單、采購發票、原材料入庫驗收單、付款單等一些列業務數據，這些數據也將做為應付款憑證以及付款憑證的原始依據企業通過內部轉換將原材料加工成商品或者服務銷售給客戶，客戶支付貨款；企業向客戶發貨或者提供上門服務以完成合同履約；客戶確認收貨以后或者服務完成，并索取發票，企業既可以確認收入這個過程中會產生銷售訂單數據、用戶支付數據、服務履約數據、銷售發票數據等業務數據，同樣這些數據也將作為收入憑證的原始數據依據相比大家都出過差，有段時間我經常去長沙出差，一般是這樣的流程，首先是在OA系統提交出差申請單，然后在攜程商務中訂購機票，領導審批完成以后出票；到了出差地訂購酒店，并且每頓飯一定索要發票用以后續的報銷等出差回來以后在OA系統提交報銷單，報銷單要寫明報銷事項、比如住宿、餐費等，并且將報銷單關聯出差申請單，提交以后還需要將紙質發票貼好以后提交到財務指定位置；這時候就可以在OA系統查看報銷流程了，如果報銷單沒有問題，提交的發票也沒有問題，那么財務審核通過以后就會將報銷款直接付款到工資卡中整個過程從出差申請、機票與酒店預訂、報銷提交都是線上化操作，不再像以前一樣需要填紙質申請單和報銷單，自己墊資購買車票和酒店費用；線上化的申請流程和報賬流程讓整個費用報銷效率極大提升，員工體驗也得到極大的提升，當然財務的工作量也降低的最小從上述列舉的流程中可以發現，業務流程中會產生大量的業務數據，而且業務流程依賴企業信息化系統完成，線下業務很難實現與財務的鏈接和融合，企業信息化是必須的；而業務流程中的業務節點會產生不同類型的會計憑證這就為我們實現從業務數據向會計數據自動化轉換提供了模型依據，同樣要能夠識別這些業務流程以及業務節點，還要就是要能夠將這些結構化的業務流程與會計憑證類型建立聯系接下來將對業務數據與結構、憑證類型、憑證結構、會計引擎基礎數據、映射規則、憑證模板、案例分析等內容進行解析
4.會計引擎
在企業經營中，財務人員通過會計憑證記錄企業的經濟活動，并依據會計憑證登記賬簿。傳統的財務工作中，會計人員根據紙質的原始憑證，依賴財務工作經驗編制分錄并錄入到賬務系統中。當企業業務復雜、數據量大時，完全依賴財務人員人工處理，效率低且正確率難以保證。但是企業的業務數據一般為顆粒度更細的明細數據，而財務數據則是需要符合會計準則的數據，因此必須先將業務數據向財務數據進行轉換。會計引擎則可以幫助解決此問題。基于以上背景，我們可以把會計引擎理解為一個翻譯工具。這需要我們提前將翻譯規則在預設翻譯器中，然后輸入業務語言，便可按照預設的規則，輸出對應的財務語言。也就實現了業務數據到財務數據的轉換，最終生成預制憑證。 首先要明確，會計引擎的目的是實現賬務自動化，即由業務數據自動生成會計憑證。那么我們可以從會計憑證出發，倒推出生成一個會計憑證都需要什么內容，從而明確會計引擎的構成。市面上比較常見的會計核算系統有金蝶、用友、SAP、Oracle，不同會計核算系統的憑證格式不同。下面我們以用友NC生成的憑證為例：核算賬簿（帳套信息）、憑證制單日期、憑證類別、會計期間、借貸方向、憑證摘要、會計科目、幣種、金額、輔助核算。可以看出，憑證是有一定格式的，并且部分內容無法從業務數據中直接獲取。基于以上，會計引擎應具備的主要功能為：
總結來說，會計引擎首先需要預設規則，然后調用相應規則，。還以上面憑證舉例，簡單列舉幾個想要生成這張憑證應配置的規則：
核算賬簿的取值規則
制單日期的取值規則
會計期間的取值規則
借貸方向的生成規則
摘要的生成規則
會計科目的生成規則
我們知道，規則的組成是：條件語句和結果語句，這放在會計引擎當中依舊適用。會計引擎規則中的條件語句由業務數據組成，結果語句則由財務數據組成。
條件==>商品類別=女裝上衣；
理解為：如果業務數據上的商品類別是【女裝上衣】時，那么對應到賬務系統中的收入成本科目為【服裝類/女裝】。在實際業務應用中，規則的條件語句可以是多個，多條件的組合邏輯可以是“或”關系“且”關系等，結果語句同理。
條件1==>公司名稱=北京xx科技有限公司
條件2==>單據類別=應收單
條件3==>商品類別=女裝上衣
條件組合邏輯“==>且”
結果1==>核算賬簿=北京xx科技
結果2==>會計科目=應收賬款/服裝類/女裝
理解為：如果業務數據上的公司名稱是【北京xx科技有限公】，單據類別是【應收單】，且商品類別是【女裝上衣】時，那么此條業務數據對應到賬務系統中的核算賬簿是【北京xx科技】，且會計科目是【應收帳款/服裝類/女裝】。以上只是介紹了會計引擎規則基本的構成，具體規則內容，還需要結合公司具體的業務場景、業務流程以及賬務處理方式等進行詳細梳理。盡管不同公司、不同業務的會計引擎內容大不相同，但配置頁面，萬變不離其宗。考慮到需要配置的規則數量大，適用場景多，我們在實際應用中可以在規則的結構上增加一級——“規則類型”以便管理和配置。通過維護規則類型，限定每類規則可以使用的條件和結果因子，縮小配置規則時的選擇范圍。下面舉例一個簡單的模型，這里我們默認條件和結果之間的判斷詞為“則”，同一規則各條件、結果之間的組合邏輯均為“且”。即：如果“條件1”且“條件2“，則“結果1”。所屬組織用來限定當前規則適用的組織范圍；條件因子和結果因子是數據庫內已有的字段，用戶通過選擇的方式任意添加（條件和結果至少各一個），添加即：指定該種規則類型對應可選的條件或結果。條件、結果下拉列表中帶出的條件因子和結果因子，會根據已選擇的規則類型決定。可添加多個條件和多個結果。條件因子的值、和結果因子的值，即所選條件和結果因子對應的枚舉值，例如：以上會計引擎的功能模型、原型頁面等都是最簡單的邏輯，在實際應用當中需要根據業務復雜程度、用戶個性化要求、服務器性能等再做相關設計。
閱讀原文：原文鏈接
該文章在 2025/2/26 12:36:55 編輯過
400 186 1886
