不同行業基本都會有自己獨特的業務，甚至同行的不同企業之間的業務邏輯也會相差千里，只有最大程度抽象出通用性、標準性和普適性的系統才能夠成爲平臺系統，平臺系統開發的成本和難度可想而知。
個人深度參與或獨立設計開發過的公共服務型平臺系統，主要包括基礎數據平臺、支付平臺、財務平臺、結算平臺、配送平臺、CRM、OA等。財務系統是業務系統中重要且複雜而龐大的一個公共服務系統。
市面上有很多成熟的財務軟件可供選擇，比如用友、金蝶和SAP等，這三種財務軟件我個人都直接開發對接和踩坑過，這樣看上去好像顯得更加專業，事實是財務系統至今仍是我最不想開發的系統，咩哈哈。
十多年前我首次接觸財務系統，在帝都某電商公司做財務開發。所謂不看不知道，一看想不到，每天和不同系統各種SQL以及不知所云的表字段命名打交道，代碼就像鬧着玩似的，倍感無力，至今心有餘悸。
和同事交流後發現，果然大家都是相似的壓抑和不爽，看代碼能當場去世的感覺。我想第一印象這麼糟糕，財務系統大概會和我絕緣，想不到離開帝都到魔都工作又機緣巧合陰差陽錯做了兩次財務系統開發。
三次財務系統開發經歷收穫不少，開闊了眼界，體驗到了複雜系統的設計和實現，當然也有明顯副作用，就是工作量太大，每次發佈上線傷害更大，但是禍兮福所倚，我的代碼自信也給磨礪了出來，咩哈哈。
一入財務深似海，從此下班是路人。財務系統實現的不好就會容易變成各路神仙的SQL和Excel奇技淫巧大賽，加班分析數據和排查各種問題是常態，不知道這算不算業界共識，反正我是親自領教過多次了。
雖然財務系統的開發體驗一度讓我想起法國作家司湯達著名的墓誌銘”活過，愛過，寫過。”，感覺心累和疲憊，但男子漢大丈夫，能屈能伸，輸人不輸陣，正所謂沒有什麼高山不能攀登，我堅信事在人爲。
迄今爲止，個人深度設計和開發過的財務系統包括的主要功能有：財務基礎、記賬、開票、報銷、借款、報稅、庫管、履單成本、往來支付、工資福利發放、財務報賬、金融保險、增值業務、供應鏈融資等。
財務系統常見的其他管理模塊如固定資產管理、現金管理、費用管理、合同管理、銀行授信、貸款管理、商業匯票、擔保管理、運輸管理、分賬管理等等，個人也有間接做過一些二次開發支持和維護的工作。
你可能已經聽說過對賬、扎帳、平帳、覈銷、T+n、應收、應付、稅控、收支、清算、結算、NC等等財務領域的術語，有很多財務專業術語還很佶屈聱牙，本文不會對這些關鍵術語進行嚴格的定義和說明。
自從見識過看一眼會升天的財務系統代碼，自我感覺再看到任何惡劣晦澀的代碼都能寵辱不驚以平常心對待，直到多年後接手了一個代碼很過分讓人腦殼疼的WMS系統，果然天外有天人外有人，咩哈哈。
根據經驗，混亂的demo型財務系統的特點包括：單據多且關係複雜，基礎數據不統一，有跨庫操作，互聯繫統間關係凌亂，數據表字段很多，命名中西合璧，幻數和枚舉極多，報表多而雜，性能不佳等。
再加上很多公司的財務系統報銷做的稀爛，每次個人報銷都感覺困難重重舉步維艱體驗奇差，很像公司要賴賬的樣子，所以我對財務完全沒有任何好感，每次用財務軟件都有忍不住重寫的衝動，咩哈哈。
雖然財務系統在個人印象中是極其複雜繁瑣費力不討好的公共服務系統，但作爲有潔癖和強迫症的完美主義者，明知工作量巨大，我還是嘗試用PowerDotNet進行重寫，爲興趣工作，挑戰不可能也是樂趣。
將財務過程流水線化是我用PowerDotNet重寫財務系統的直接動力，但還是低估了體力活的大小，恰巧有段時間心情特別特別好，對寫代碼熱情高漲，去粗取精揚長避短大事化小小事化無一通操作就寫完了。
用PowerDotNet重寫後的財務平臺，模塊劃分明確清晰，功能穩定，靈活性和可擴展性極好，實現優雅，可維護性也很強，良好的工具會讓人更自信更喜歡編程，更讓人積極熱愛自己的編程事業，咩哈哈。
因爲不同公司的主業務不同，財務系統的側重點也會有不同，PowerDotNet這裏介紹的財務平臺，只是個人所從事的電商財務管理系統中很基礎的通用功能的一部分，當然也預留了特殊業務的可擴展性。
PowerDotNet的財務平臺系統設計和實現做了很多取捨和痛苦抉擇，很多特定行業或定製化業務沒有吸收整合進去，畢竟PowerDotNet最初的主要目標是要實現一套能夠被絕大多數公司通用的公共服務。
麪條代碼 (Spaghetti Code)常有，麪條系統也不少見。支付、財務、CRM、配送等系統，解耦做不好，很容易變成麪條系統。麪條系統的解耦難度遠比業務系統按服務、模塊或應用等進行劃分解耦難得多。
PowerDotNet的財務平臺系統在系統解耦方面做了極大努力，非常考驗開發經驗和業務廣度，因爲根據個人經驗，電商財務系統和商品、庫存、CRM、訂單、支付、配送等系統有藕斷絲連曖昧不清的關係。
混亂的Excel需求和各種數據庫連接是財務這種容易解耦失敗變成麪條系統的直接體現。遵循PowerDotNet的開發接入規範，可以大大降低麪條系統出現的可能，哪怕是財務或者WMS這種特別複雜的系統。
本人有多年一線編程經驗和代碼量的積累，PowerDotNet正是積累的直接產物，現在個人遇到技術和業務難題，不敢說隨心所欲信手拈來，卻也有一整套相對完備成熟可行的解決方案或思路，並且屢試不爽。
對於複雜的CRUD業務邏輯型開發來說，應對各種變化是大概率事件，因爲“唯一不變的是變化本身”。來說是非者，必是是非人。PowerDotNet不是空口無憑嘴上說說而已，而是拿出實踐成果來證明自己。
編程是非常講究動手實踐的科目，在絕對實力面前，一切方法論高情商都是務虛的浮雲。 事實勝於雄辯，只有把良好的軟件務實設計開發出來，才能證明事情做對了，同時你會不知不覺中發現路也走寬了。
軟件開發普遍認爲造輪子比調包調參更高級，PowerDotNet早期也是深受這種說法影響，僅限於框架工具研發，但個人現在的看法和做法已與過去不同，技術服務於業務，軟件開發離不開業務的積累和抽象。
對於複雜的業務開發，尤其是支付和財務結算這類複雜的中大型系統，代碼的業務可讀性和可維護性尤爲重要，PowerDotNet總結了前人開發經驗，在代碼業務可讀性和可維護性方面做了很多實踐和探索。
PowerDotNet和PowerDotNetCore不能保證系統設計和實現的上限有多高，但至少能保證下限不低，因爲它們可以提供統一的編程規範，而且完善的基礎設施和公共服務的高度抽象和複用更便於系統實現。
雄關漫道真如鐵，而今邁步從頭越。PowerDotNet和PowerDotNetCore目前在財務系統開發上已經小有所成，但距離好的精品財務系統目標還相去甚遠，財務開發道阻且長，這點個人有非常清醒的認識。
環境準備
1、（必須）.Net Framework4.5+
2、（必須）關係型數據庫MySQL或SqlServer或PostgreSQL或MariaDB四選一
3、（必須）PowerDotNet數據庫管理平臺，主要使用DBKey功能
4、（必須）PowerDotNet配置中心Power.ConfigCenter
5、（必須）PowerDotNet註冊中心Power.RegistryCenter
6、（必須）PowerDotNet緩存平臺Power.Cache
7、（必須）PowerDotNet消息平臺Power.Message
8、（必須）PowerDotNet文件平臺Power.File
9、（必須）PowerDotNet個人用戶管理平臺Power.PCRM（後續詳細介紹）
10、（必須）PowerDotNet人員管理平臺Power.HCRM
11、（必須）PowerDotNet基礎數據平臺Power.BaseData
12、（必須）PowerDotNet定時任務調度平臺Power.TaskSchedule
13、（必須）PowerDotNet數據同步平臺Power.DataX
14、（必須）PowerDotNet支付平臺Power.Payment
15、（必須）PowerDotNet商品管理平臺Power.Commodity（後續詳細介紹）
一、財務基礎
財務基礎數據包括財務專用基礎數據、外部業務系統基礎數據和全局通用基礎數據。
1、財務專用基礎數據
比如收支項目、費用類型、結算方式、賬期類型、稅率、銀行類型、銀行信息、銀行賬戶等，這些數據基本都是財務系統內專用，其他業務系統很少用或者不用，就算要用也是提供接口低頻調用。
2、業務系統基礎數據
財務和外部互聯互通的業務系統非常多，常見的比如商品、採銷、支付、配送、倉儲、人員管理等，後面介紹電商財務系統會和哪些常見的業務系統進行互聯互通。
使用依賴的業務系統的基礎數據，常規有三種方式，PowerDotNet都給出了完美支持
（1）直接連接業務庫查詢，有了DBKey這非常容易，但是極不推薦這樣做
（2）調用業務系統查詢接口，這是我們所推崇的服務化方案，有了服務治理，開發工作量並不大
（3）在財務系統裏冗餘一份數據，通過數據同步平臺同步基礎數據至財務庫，開發人手不足的情況下，這是最優方案
3、全局通用基礎數據
比如區域、證件類型、幣種、語言、應用終端類型、公司信息、組織信息等，從基礎數據平臺可以輕鬆獲取這些數據，PowerDotNet重寫的財務平臺主要藉助數據同步平臺同步數據至財務庫。
萬丈高樓平地起，財務基礎是沒什麼技術含量純HelloWorld型體力活，但它卻是財務平臺穩定可靠運行的基石，根據我的經驗，混亂的財務系統通常都能看到基礎數據的隨意變更痕跡。
不重視基礎，就是不尊重軟件開發規律，任何輕視基礎數據抽象設計和管理的公司遲早都要受到懲罰。
二、財務應收
財務平臺設計與開發涉及到大量專業的財務和會計知識，深入理解這些業務知識對開發人員的好處顯而易見，在財務系統中最常見的就是各種往來賬，比如應收賬款和應付賬款，預付賬款和預收賬款等。
本文根據個人開發過的財務結算系統常見的劃分方式進行總結，對於一般公司而言基本夠用，但實際開發應結合公司業務需要進行規劃開發和管理，本文所寫的單據和業務分類僅供參考。
財務應收屬於通常我們所說的AR範疇。
1、應收單
應收單單據的抽象是企業應收賬款的直接體現。
應收賬款是指企業在正常的經營過程中因銷售商品、產品、提供勞務等業務，應向購買單位收取的款項，包括應由購買單位或接受勞務單位負擔的稅金、代購買方墊付的各種運雜費等。
應收賬款雖然是你的資產，但它現在畢竟在別人兜裏，能否收回來是個未知數，所以應收賬款非常的“虛”。如果應收賬款佔總資產的比重過大，企業的財務模型可能非常不健康。
2、收款單
應收單是應收，還沒有收到手裏，收款單則偏重於實收，收款單通常是在應收賬款收到的情況下進行創建，但也支持特殊業務需要，先創建收款單而後真正收款到賬。
以一個電商場景舉例，國內機票商戶創建訂單，調用支付平臺接口或跳轉到支付平臺完成支付後，得到支付單結果，國內機票變更訂單狀態，做其他相關業務邏輯，最後在財務平臺創建收款單。
3、應收退款單
應收退款單可以認爲是收款單的逆向單據，一個收款單可以創建一個或多個應收退款單。
在支付平臺裏我們已經介紹了支付單有三種常見類型，即扣款支付單、退款支付單和擔保支付單。應收退款單發起的真實退款在支付平臺都有體現。
以一個電商場景舉例，國內機票商戶訂單支付完成後，個人用戶或者企業用戶發起退款，我們通常有兩種鏈路模式進行退款處理：
（1）國內機票商戶直接調用支付平臺接口進行退款，得到退款支付單結果，國內機票變更訂單狀態，做其他業務邏輯，最後在財務平臺創建應收退款單。
（2）國內機票商戶調用財務平臺創建應收退款單接口，財務人員在財務平臺審覈並調用支付平臺接口退款，支付平臺回調通知財務平臺，財務平臺回調通知商戶，商戶做退款後業務邏輯。
根據個人開發經驗，建議使用（1）這種處理路由，因爲這種模式給了商戶更多的靈活性，鏈路也相對簡短一點。
4、應收發票
應收發票是開票模塊最重要的業務功能之一，涉及非常多的財務業務邏輯，包括稅控、創建財務應收、代收代付、紅衝、發票文件處理、虛擬開票、票據作廢等。
5、應收對賬
對賬同樣也是財務平臺的重要模塊。在單據多且雜的財務系統中，主要單據的對賬功能必不可少，對及時發現和解決業務問題有不可或缺的作用。
在支付平臺裏我們已經簡單介紹過對賬功能，支付平臺分擔了一部分財務對賬功能，系統解耦更加合理。
財務單據對賬更偏重於實際業務單據的數據比對，而不僅僅是支付或退款數據。
6、應收覈銷
財務系統覈銷單也是很常見的單據，但是覈銷單功能並不是必須的，如果人手不足，可以簡化設計直接在業務單據上進行覈銷處理而不用獨立設計覈銷單。
小結：從我們熟悉的電商系統角度看來，財務應收更加直面終端用戶，線上和線下業務都能覆蓋，更加偏重於B2C，但B2B也能很好支持。
三、財務應付
財務應付屬於通常我們所說的AP範疇。
根據個人經驗，AP應付模塊和供應鏈管理、庫存管理、金融、運營等業務平臺深度綁定，財務業務邏輯的複雜程度和業務部門的需求有直接關係，所以通用型財務平臺是真不好寫。
1、應付單
和應收單類似，應付單單據的抽象是企業應付賬款的直接體現。
應付賬款是會計科目的一種，用以覈算企業因購買材料、商品和接受勞務供應等經營活動應支付的款項。
應付賬款通常是指因購買材料、商品或接受勞務供應等而發生的債務，這是買賣雙方在購銷活動中由於取得物資與支付貨款在時間上不一致而產生的負債。
2、付款單
從企業自身角度出發，收款單是收取個人用戶、企業用戶或者供應商的錢，也就是掙錢；付款單就是將企業的錢花出去給到個人用戶、企業用戶或者供應商，也就是花錢。
付款單根據經營對象的不同，又分爲經營性付款單和非經營性付款單，這一節寫的是經營性付款單，主要面向企業用戶或者供應商，後一節單獨寫非經營性付款單。
付款單真正付款，前期哪怕已經被審覈確認通過，最後提交真正轉賬付款時也需要財務人員再次確認付款信息，防止誤操作導致不必要損失，出問題了也可以說是業務操作問題，這就是嚴謹^_^。
3、應付退款單
應付退款單又稱應付退貨單，主要處理公司付款後，因爲各種問題導致公司退貨至企業用戶或者供應商的單據。
應付退款單的主要業務邏輯可以看做是付款單的逆向單據，但是實際情況是非常複雜多變的，比如因爲供應商問題，常常導致公司無法拿到退款而產生壞賬。
4、應付發票
和應收發票相比，應付發票邏輯就簡潔多了。根據個人經驗，應付發票經常要和Excel、PDF、圖片等類型的文件有直接聯繫，處理不好，也會加重財務人員處理票據的效率和準確性。
5、應付對賬
應付對賬和應收對賬類似，主要用於查漏補缺，對於業務邏輯極其複雜且款項很多金額很大的財務應付單據來說，每一筆單據對賬都要非常到位纔行，否則財務月結必然困難重重。
6、應付覈銷
和應收覈銷非常相似，應付覈銷單主要是由AP相關單據的核銷操作而產生。
7、應付催款
應付催款單主要是由AP相關單據的審計或對賬操作而產生，無法收回的款項就會形成壞賬，應付催款單經常和壞賬聯繫在一起。
小結：從我們熟悉的電商系統角度看來，財務應付更加直面B端企業或者供應商，更加偏重於B2B。
四、非經營性付款
非經營性付款仍然屬於AP應付範疇，非經營性可以直觀理解爲不參加企業的生產經營活動，不能直接地爲企業創造價值和帶來收益，和經營性付款有顯著區別。
1、非經營性付款單
非經營性付款單主要來源包括（日常、差旅和業務招待）報銷單、借款單和付款申請單，其中報銷單和借款單主要針對企業自己的僱員，所以通常和人員管理或者OA有直接聯繫。
非經營性付款單真正付款，和經營性付款單處理流程基本一樣，不能和錢過不去，最後提交真正付款時也需要財務人員再次確認付款信息，防止誤操作導致公司或個人不必要損失。
2、報銷單
3、借款單
4、付款申請單
5、工資福利發放
非經營性付款單也是付款單的一種，需要通過支付平臺將公司的錢轉賬到用戶。
財務系統維護了一份人員賬戶信息，便於通過支付平臺進行轉賬匯款操作，這樣財務平臺和支付平臺、人員管理平臺HCRM就可以實現互聯互通了，報銷、借款、工資福利發放等功能實現易如反掌。
五、簡易工作流
1、流程設計
財務平臺像OA系統一樣，經常有需要將單據做各種業務流程控制，比如單據審批、對賬、覈銷等操作，這就涉及到工作流的設計和實現，工作流是獨立的基礎框架軟件，不是本文重點，僅作參考。
PowerDotNet設計實現的財務簡易工作流主要有流程模板、流程規則、流程實例、流程節點（步驟）、流程節點日誌共5張表，配合HCRM，支持單據撤銷、通過、駁回、退回到某步驟這幾種常見處理。
2、流程模板
財務簡易工作流主要包括兩大類流程模板，即應收流程審覈模板和應付流程審覈模板，業務處理狀態僅包括撤銷、通過、駁回、退回到某步驟四種，功能雖然不太全，但是一般財務業務單據基本夠用。
應收流程審覈模板，處理步驟相對較少，通常創建好應收單，普通財務人員審覈即可，一般不需要財務總監或者更高級別人員審覈，有些應收單據甚至在程序自動簡單校對後可根據定時任務自動審覈。
應付流程審覈模板，相比應收流程，應付流程往往更加嚴格，步驟也多，除了普通財務人員，往往需要總監或更高級別人員二次或三次審覈，畢竟應付是要公司大筆花錢出去，出了問題後果很難承受。
3、流程處理
目前實現的財務簡易工作流，支持應收和應付常見單據處理流程，但是內部還是有不少和人員相關的業務邏輯判斷處理，和HCRM耦合較深，狀態判斷也不夠靈活，這是財務簡易工作流不足的地方。
工作流規則是不怎麼會變化的，但變化又是確實存在的，比如付款單審覈用到的付款額度規則，可能超過N萬就要總監審批，N就會根據需要調整，這種就容易出現歷史單據和當前配置規則處理不一致。
解決的方法也很簡單，每次創建流程實例，將當前流程規則自動生成實例規則，實例僅和實例規則匹配，這樣就達到歷史數據就按照歷史規則進行處理，新流程數據按照新規則進行業務處理的目的。
財務簡易工作流已支持業務人員審覈、財務專員審覈和財務總監審覈，但是單據審覈和工作流處理緊密相連不好移植，很難獨立出通用的財務工作流抽象，這是我不推薦這個簡易工作流的主要原因。
六、庫存單據
庫存單據管理主要包括庫存入庫、庫存出庫和庫存盤點等，其中入庫類型又可分爲採購入庫、調撥入庫、移倉入庫、銷售退貨等，出庫類型可分爲銷售出庫、調撥出庫、移倉出庫、採購退貨等幾種類型。
庫存通常都在WMS或進銷存系統中管理，爲了解耦，財務系統理論上是不需要單獨存儲庫存單據的。但根據經驗，財務單據經常要查詢庫存業務數據，可以根據業務需要將固化的庫存數據寫入財務。
庫存系統中數據量較大或者經常變動的數據，比如庫存流水、庫存快照等，不建議存儲在財務系統中，WMS和財務的庫存單據我都親自開發過，也算是見多識廣了，咩哈哈。
作爲資深且涉獵廣泛的程序員，對於庫存和秒殺這樣的有較高技術挑戰的公共服務型系統，如果沒有親自開發過不能不算一種遺憾。
通常介紹到這裏你就知道我可能要在某個有空的時候寫寫庫存系統了，是的，幾年前我確實爲庫存系統搬過磚，本人就是這樣全面，但是說實話庫存系統通用性比支付財務CRM等系統差遠了，咩哈哈。
1、庫存入庫
2、庫存出庫
庫存入庫和出庫涉及到每筆庫存的流水，財務平臺也有詳細的流水記錄可供查看。
七、財務報表
財務報表是財務系統必不可少的也是開發人員繞不開的一個重要功能模塊，大公司裏往往會產生各種財務報表，兼有各種酷炫展示，通常開發工作量非常大且枯燥。
常見報表需要支持餅圖、柱狀圖、折線圖等，報表可視化通常需要開發後端報表元數據管理模塊，也需要前端和客戶端技術支持，當然這不是本文重點，順帶一提。
報表需求的一個常見情形是很多中小公司跟風搞大數據，強擼“低代碼平臺”，連接各個系統數據庫，拼接sql，不好查詢的就跨庫硬查，放在前端用漂亮的圖表顯示出來，或者再投到大屏上，很高級的樣子。
報表這種對查看使用的人友好，必然對開發維護的人不友好。個人經歷的業務系統報表需求，尤其是支付財務方面的報表，簡直可以直接寫一個“你沒見過的爛代碼”系列。
PowerDotNet實現的財務平臺對報表開發進行了歸類分析和總結，根據數據特徵分組，我們通常可以將數據分爲結構化數據、半結構化數據和非結構化數據三種。
結構化數據：一般是指可以使用關係型數據庫表示和存儲，可以用二維表來邏輯表達實現的數據。
半結構化數據：是結構化數據的一種形式，它並不符合關係型數據庫或其他數據表的形式關聯起來的數據模型結構，但包含相關標記，用來分隔語義元素以及對記錄和字段進行分層，數據的結構和內容混在一起，沒有明顯的區分，因此它也被稱爲自描述的結構，簡單的說半結構化數據就是介於完全結構化數據和完全無結構的數據之間的數據。例如：HTML、Markdown、JSON、XML和一些NoSQL數據庫等就屬於半結構化數據。
非結構化數據：顧名思義，就是沒有固定結構的數據。
非結構化數據包括所有格式的辦公文檔、文本、圖片、多媒體文件等都屬於非結構化數據。對於這類數據，我們一般直接整體進行存儲，而且一般存儲爲二進制的數據格式。
PowerDotNet財務系統的報表開發，主要支持結構化數據，對於非結構化或半結構化數據，要麼間接轉爲結構化數據，要麼放在大數據平臺/ETL進行處理，不建議直接在關係型數據庫上設計XML或者JSON格式的字段，哪怕關係型數據早就支持這些字段類型。
PowerDotNet實現的財務平臺根據日常報表需求抽象提取出了常用的導入導出模板，日常報表導入和導出功能通常只需要配置下模板一行代碼即可搞定。
PowerDotNet實現的財務平臺支持應收、應付、發票、對賬、轉賬、非經營性付款、NC管理等主要模塊的常見報表功能，也開發了一個便於開發人員拉取數據的萬能自定義報表功能。
1、簡單報表
PowerDotNet開發的財務平臺，對於常見的財務單據，都開發出了導出Excel功能，滿足絕大多數財務基本需求。
2、複雜報表
在財務報表模塊我是經常碰到洋洋灑灑幾百上千行十幾二十個表join連接查詢的SQL，子查詢嵌套子查詢是常態，跨庫查詢也不在話下。PowerDotNet會全力拒絕出現這種難以維護的SQL出現。
雖然報表開發通常都很複雜，但作爲一名3000多行復雜SQL語句曾經的直接受害者，個人強烈建議SQL Boy要向CRUD Boy轉變，思路換一下，程序的可維護性、可擴展性甚至靈活性都大大加強。
對於複雜報表，PowerDotNet有三種處理方式。
第一種是實時join連表查詢，相對而言sql也不怎麼複雜，對於數據量不大的單據，這種就能快速解決問題。
第二種是藉助PowerDotNet的數據同步平臺和定時任務平臺，將報表數據結轉到一張表或幾張表，非實時的財務報表的生成和查詢邏輯可以大大簡化。
第三種是針對財務系統單獨創建報表數據庫ReportDB，通過數據庫的同步功能或藉助PowerDotNet的數據同步平臺和定時任務平臺，專門生成報表，和第二種唯一區別是新增一個報表數據庫。
根據個人經驗，對於複雜報表，尤其是涉及到多系統的數據查詢，定時生成寬表（大表）幾乎不可避免的，否則報表查詢的SQL將會是開發者和維護者的噩夢。
3、萬能報表
稍微懂點財務和技術的業務人員對SQL總有一種執念，所以還是需要暴露萬能報表功能給業務以備不時之需。你要說這樣玩不安全，當業務系統和數據庫系統權限控制是喫素的？
八、NC管理
個人開發業務系統曾經對接過用友NC和金蝶EAS，也對接過SAP，對這三種財務軟件相對有點了解，本文以比較熟悉的用友NC舉例。
1、NC基礎
NC基礎和財務基礎一樣，導入NC必備，雖然沒什麼技術含量但是需要好好開發管理起來，否則各種基礎數據問題很容易導致混亂。
2、NC應付
3、NC付款
4、已導入NC單據
爲了防止重複導入，需要加一層已導入NC單據，主要的應收和應付財務單據表都設計一個是否導入NC字段就沒有必要了，當然多一個冗餘字段也沒有任何問題。
相比金蝶的EAS，導入NC需要二次開發很多東西，但是NC財務功能也更強大更完善。
5、定時導入NC
有了PowerDotNet定時任務調度平臺Power.TaskSchedule和服務治理平臺，只需要在財務系統開發Job接口，在定時任務調度平臺點點按鈕配置即可。
通常支付和財務都有很多定時任務，我個人傾向於把支付和財務分在不同分片單獨進行處理，當然如果對性能相對沒有要求，也可以把它們放在一個分片處理。
九、支付管理
支付和財務聯繫實在是太緊密了。
在支付平臺裏我們已經介紹過，爲了將財務和支付完全解耦，讓財務平臺專注於財務方面的事情，支付平臺專注於支付方面的事情，比如對賬功能，財務平臺可以直接調用支付平臺接口。
當然根據個人開發經驗，財務系統經常需要排查支付相關問題，爲了在財務平臺更好的排查支付或退款等問題，這裏列出財務平臺對支付功能的補充。
1、轉賬回調
每一筆轉賬匯款都有回調數據由支付平臺通知到財務平臺，兩個平臺雖然有數據冗餘，卻極大地提高了高頻數據查詢效率。
2、支付工具
有些應急單據可以直接在財務平臺後臺頁面快速查詢或者處理退款等操作，也可以按部就班，商戶創建退款單，財務平臺審覈，支付平臺發起真實退款，按照業務需求模型來完成邏輯。
對於多商戶系統，財務平臺支付工具的開發非常有利於解決各種各樣的支付或退款問題，這是多年開發經驗實踐而得出來的結論。
十、稅控管理
1、稅控盤
稅控盤是一種專用的稅控裝置，按照國家稅務總局的“稅控盤技術規範”進行研製。
金稅盤和稅控盤都可以用於開具增值稅專用發票和增值稅普通發票，也能開具貨運專票和機動車發票。
個人開發財務系統使用過百旺稅控盤，瞭解膚淺，不求甚解，小記一下，咩哈哈。
2、稅控發票
稅控發票主要包括開票設置、開票、發票作廢、發票打印、發票上傳等核心功能。
這一塊需要實際開發財務頁面才能理解，我的印象中百旺稅控盤用到了古老的ActiveX技術，有瀏覽器兼容問題，好像IE兼容最好，有些國產瀏覽器也能正常使用。
十一、財務回調
和支付平臺類似，財務系統裏也有大量的回調和補償操作，定時任務調度平臺Power.TaskSchedule真是功不可沒。
回調通知必須做好接口串行化和業務數據冪等性處理，防止高併發情況下導致的單據重複創建。
1、業務系統回調財務平臺
典型的如訂單系統（各個商戶）、支付平臺、門店系統、結算系統等通過財務平臺接口創建財務單據，完成互聯互通。
2、財務平臺回調業務系統
主要功能就是在財務平臺完成單據業務邏輯後通知各個業務系統財務處理結果。
正是因爲支付、財務、訂單等系統的回調非常頻繁，藉助服務治理平臺，PowerDotNet的回調可以大大簡化，完全可以抽象成一個獨立系統或應用專門處理回調通知邏輯，減少各個系統的重複建設。
十二、文字識別
個人開發過的主要功能，就是基於OCR的文字識別功能，自動識別發票圖片上的發票號和財務業務單據進行關聯處理，接着將發票圖片自動轉換爲pdf文件最後上傳文件服務器。
這部分功能主要偏重於客戶端程序實現，當然也做了網頁版自動識別補償程序，不過客戶端跑的非常穩定，網頁版幾乎沒有用到。
十三、互操作
和支付平臺類似，財務平臺也需要調用很多二方庫三方庫甚至要通過外部SDK進行socket通信處理（碼槍、高拍儀、自助開票機等），在稅控處理模塊還可能需要使用古老的ActiveX技術。
我們可通過regsvr32命令行註冊COM組件直接在項目中引用DLL，或者通過DllImport實現互操作，這些可參考支付平臺互操作一節，本文不再贅述。
十四、系統交互
財務平臺和很多內部業務系統保持互通關係，有些公司很多業務系統都必須圍繞財務平臺開展業務活動，不然會引發各種混亂，整理下個人開發和對接過的幾種常見互聯繫統。
1、訂單系統
這裏的訂單系統可以直接理解爲支付平臺抽象出來的商戶系統，比如電商領域常見的各種業務訂單、賬戶充值等，都可以抽象爲商戶訂單系統。
PowerDotNet實現的財務平臺提供了所有商戶支付和退款的兜底方案，如果商戶系統因爲業務邏輯頻繁改動而造成支付和退款業務難題，財務平臺可以代勞。
2、支付系統
在支付平臺裏已經對支付和財務之間的關係有詳細介紹，這裏不再贅述。
3、CRM
財務系統和HCRM、PCRM及ECRM都有緊密聯繫，不論是偏向B2C業務的應收還是偏向B2B業務的應付，都離不開和人打交道。
4、結算系統
結算系統我個人也親自開發過，甚至模塊劃分AR、AP、發票、對賬單這些都幾乎相同。
我個人參與開發過幾個複雜而重要的結算應用，手頭還有源代碼，C#和Java版本的都有，但我對它們都不太滿意，甚至短期內也沒有寫出來介紹的衝動，咩哈哈。
毋庸置疑，財務和結算聯繫最緊密，很多公司都把兩者放在一個系統中進行開發。
5、賬戶系統
賬戶系統可以抽象理解爲一個支付商戶（特殊的訂單系統），賬戶的充值、提現、支付和退款都需要在財務系統中有體現，都要有詳細的往來賬流水。
6、商品系統
毫無疑問，企業在正常的經營過程中，必須有銷售商品、產品、提供勞務等業務，訂單系統主要提供商品售賣服務，所以商品（含虛擬商品）系統必然是和財務系統緊密聯繫在一起的。
商品也是大多數企業非常重要的核心業務系統，某些特殊場景除了商品，還要考慮輔料、原料（物料）等，商品管理系統的設計直接關係到採銷、財務、訂單等核心業務系統的複雜度。
7、庫存系統
如你所知，庫存系統主要用於管理商品庫存，主要包括商品入庫和商品出庫。
商品主要由供應商提供，我們常見的企業進銷存系統或採銷系統或倉儲WMS系統或供應鏈系統等都和庫存緊密相關，可以算作庫存系統的核心。
8、門店系統
門店系統主要經營企業線下業務，相較於線上業務，線下業務模式可能遠遠不同於線上，但門店系統的經營活動最終也會將各業務單據寫入到財務系統中去。
9、票券系統
財務系統記賬時可能需要記錄票券系統的單據號，這些單據號主要用於分析對賬和排查問題，這樣票券系統就和財務系統產生關係，不過這種聯繫並不算非常緊密。
10、其他系統
其他如運營、活動等電商業務系統也和財務有些聯繫，根據業務需要，這些系統和財務都會或多或少有交互，本文就不再介紹了。
小結：個人認爲開發好財務系統，需要深厚的專業知識和技術積累，也需要高屋建瓴的抽象和洞若觀火的編碼能力，還需要不同系統組織和管理的支持，否則財務系統很可能拖泥帶水成爲業務發展的瓶頸。
十五、其他
本人開發過的財務平臺的其他主要功能還包括：
1、補償和重試
因爲財務和各個業務系統互聯互通非常頻繁，所以需要定時做補償和重試操作，和支付平臺類似，藉助定時任務調度平臺，這些都是沒有難度的體力活，寫寫接口配置下補償和重試job即可。
2、敏感數據脫敏處理
財務敏感數據必須加密存儲，比如人員賬戶信息等必須賦予最高數據安全性。
3、數據結轉與備份
和支付平臺一樣，自從用了DataX數據同步平臺，這一塊幾乎不用寫任何代碼了，咩哈哈。
4、財務監控
和支付平臺類似，也根據實際業務和部署情況，抽象出財務業務正常指標，按需動態配置監控和預警參數，可進行短信、郵件、釘釘、微信等方式進行業務告警。
對於轉賬付款等和金錢有關的操作要設置安全付款額度指標，超過額度就給相關財務人員發送預警提示。
5、財務接口安全
財務平臺所有信息敏感的（尤其是和錢、餘額、積分、資金、流水等相關的）接口必須經過嚴格的授權、鑑權、認證（校驗token）、驗籤等操作，這些都是服務治理平臺分內的事情。
6、成本中心
主要功能包括履單成本和運營成本，單據實現和AP付款單有很多相似之處，對於公司成本控制有直接幫助。
7、商務排款
AP模塊重要功能，根據公司政策，給各採銷小組分配額度，實現對供應商的有計劃的付款，主要包括財務基礎配置、額度管理、排款管理、稅票管理和付款管理。
8、增值業務
增值業務通常是公司主業之外的副產品，也就是副業，某些公司的副業絕大多數不如雞肋，食之相當無味，棄之毫不可惜，說不定等你辛苦開發完了，公司倒閉也沒用到，咩哈哈。
9、財務報帳
偏重於企業臺賬的流程管理，主要單據包括報銷申請單、借款申請單、付款單、收款單、立項申請單等。
10、供應鏈融資
主要抽象出借款單、還款單、利息單、費用單等單據用於實現供應鏈融資管理，對於傳統財務開發來說，還算有點業務上的亮點。
11、存貨覈算
涉及到物料、商品、庫存等業務單據複雜的財務邏輯計算，和採銷、生產加工以及庫存管理密切相關，可能還要和SAP等系統對接。
12、金融保險
此金融保險非彼金融保險，業務需求多樣隨意的結果就是命名多樣而隨意。
13、發票打印
發票打印模塊個人開發過的最重要的功能是打印模板的製作，以及瀏覽器插件的安裝和各種兼容問題排查，說多了都是淚，就讓這一切都隨風去吧，咩哈哈。