財務自開發系統的一些想法（實現篇）

財務系統自開發的一些理解（實現篇）

Thursday, October 27, 2016

11:30 AM

 

  理論篇論述了幾類財務系統的概述和問題，那麼在關於這幾類財務系統如何開發實現將在本文中論述。

  

  首先，本人大部分實現的經歷是基於SAP，或者用友，工作初期是ERP系統自開發經驗，也有些小眾系統使用過。這個也是現在現狀，因為現實中大部分公司都會使用已有的財務系統，上文也論述過，財務系統的是有統一規範（財務準則），統一要求（三大標準輸出），統一操作（複式記賬，借貸項），所以對於大部分常規公司來說，的確沒有必要重複造輪子，在市面上隨便賣一個U8就可以了，而去大部分會計都熟悉使用，用不著專門培訓。

 

  但是，但是，隨著現在大量網際網路公司出現，尤其是新的業態和新的公司型別。大量網上交易和複雜的收付款結算點，使得傳統的通用+定製的財務軟體有的無以為繼。比如之前一段時間，蘇寧雲商網際網路商場的大量訂單，對以SAP為核心的系統巨大壓力，現在蘇寧也準備往自開發方向轉移。從現在來看，對於網際網路公司金融公司，自開發系統可能是一個現在方向。

 

一、自開發財務系統和通用定製財務系統比對論述

   現在我們在論述下財務系統的自開發之前。首先說下財務系統開發的幾大基礎。

·        基本操作：複式記賬，一借一貸，必須相等

·        基本規則：財務準則；一般必須滿足國內財務準則，主要在資產折舊，期間結算，報表出局方面。強大的

·        基本實現要求：能爭取出局三大報表，有些地方不需要現金流量表，但是至少必須出具資產負債表和損益表。負債表是相關資產負債科目餘額合計等到，損益表是損益類科目餘額合計而成，表結法是現在比較流行結算方法。具體實現邏輯網上很多。

·        必須存在的主資料：會計科目表，公司貨幣，財務年度，憑證型別設定等。

     滿足上面需求，基本就可以算是一個合格財務系統。

     自開發財務系統和通用財務系統都是一樣，必須滿足上面提到的幾大基礎。滿足以後，基本就是滿實現了最基礎財務系統的要求。

      綜合來說，自開發財務系統就是通用定製系統最大區別整合程度，如果對於報表行財務系統卻別不大，但是對於系統整合型和管理型財務系統會有很大區別。對於如果使用用友SAP作為財務系統，而外圍系統使用其他自我開發系統。必然存在以下情況：

·        整合度不高：介面多，資料庫和資料表分離：因為多個平臺需要進行資料傳輸，而且往往因為使用不同資料庫，需要頻繁傳輸資料；而外圍單據實時生成財務憑證，往往這些介面成為系統瓶頸。甚至如果在大型促銷階段，由於很多訂單迴轉（確認後取消）會對整合度有很高要求。

·        分析資料孤立：因為多個系統，當進行綜合分析時候，需要跨資料表查詢時間；查詢時間長，因為跨多個系統，如果涉及到財務系統和其他系統資料

·        管理型財務系統難以實現：因為管理型財務系統是對於公司內部進行管理，其實已經深入各個分支業務系統；傳輸不單單是財務憑證，也包括成本資料，KPI資料，工時資料，產成品資料；由於傳輸的資料更多，難以顯示。

 

       額外的話，對於SAP來說，基本都是整體實施，就是SAP的財務模組和採購，銷售，人力管理模組和生產模組一起上線；這樣才可以實現真正的管理型財務系統。如果單純使用SAP作為財務系統，外圍系統使用其他系統，這樣只能達到系統整合型的階段；如果外圍系統和SAP的介面並沒沒有到實時產生財務憑證，而且簡單的在每日製定時間傳輸；這樣的SAP財務模組只能發揮比報表型財務系統略高階段。

 

二、各個不同型別財務系統自開發設計論述

1、報表型財務系統開發

        報表型財務系統的自開發和通用區別：自開發和通用差別不大。卻別就是具體實現方式，通用財務系統可能在一個C/S傳統架構，或者是B/S架構，但是底層處理比較傳統。自開發更為隨意，可以直接在Excel表加入VBA和宏實現；或者直接資料庫加WEB前段進行表操作。甚至可以不用MySQL/Oracle這樣後臺，直接在文字上進行處理。

·        核心內容：報表型財務系統主要涉及財務操作人員，可以說是把基本財務操作透過計算機進行記錄，出具財務報表。較為簡單，開發實踐也很簡單。

·        調查物件：財務部門會計經理，記賬人員

·        工作流程：調研財務人員需求，確定財務主資料，科目表，日常常見操作，是否有介面需要，是否需要進行多個公司管理等；然後進行開發上線。

·        調研關注點：科目表制定，國內大部分公司都有標準的科目表價格，8位到10位，具體可以百度查詢之，但是各個公司會有自己特點。同時就是常見憑證型別，比如收款憑證，採購憑證，這些常見憑證可以快速拉出，減少工作量。

·        開發設計：報表型財務系統開發較為簡單。前臺分為憑證輸入介面，科目餘額查詢介面，主資料維護介面和報表生產介面，現在大部分都是透過WEB頁面實現。後臺主要是科目資料表；憑證表，一個憑證可以是一個統一編號多條資訊，憑證號為統一憑證索引，有借貸項，金額，科目號，備註等欄位；然後每個科目可以按照借項和餘額紀錄金額，方便快速查詢。

·        設計難點：主要難點在科目表，和預設科目。還有就是這個比較簡單，因為是操作人員直接輸入，可以加入約束條件，以防不實際的資料輸入。或者進行多次確認。

·        開發難點：基本無難度。

·        介面和擴充套件：

o   憑證匯入介面：操作人員可以透過Excel或者TXT批次製作財務憑證輸入，提供工作效率

o   報表匯出：生成的報表可以匯出Excel，這個沒有什麼問題好說

o   多個帳套：如果一套財務管理軟體需要管理多個公司，在這裡有個侷限性，有兩個方式，一個是加入公司程式碼欄位，在每次憑證和查詢時候需要輸入。或者使用帳套功能，每個公司一個帳套，這樣設計比較簡單。個人建議使用一個帳套，多個公司程式碼，這些如果進行集團公司出具合併報表時候，可以進行定製。

o   集團公司合併報表：這個就很有意思了，包括科目組設計，同時公司間交易需要對沖。其實原理上來說資產負債表就是按照科目餘額相加合併，如果部分控股按照百分比進行計算。損益表需要扣出相關公司間交易金額。

 

2、系統整合型財務系統開發

        報表型財務系統主要透過手工記錄財務憑證，產生法定法務報表；隨著公司資訊化深入，大量財務憑證和主資料可以透過外圍系統觸發傳入，透過介面或者直接整合方式，可以大大提高工作效率。同時由於業務單據需要對應財務憑證驗證，財務憑證有業務單據為源頭，也提高了業務憑證和財務憑證的可靠性。

整合型財務系統的自開發和通用區別：就像上文所說，主要區別就是整合程度，大多數單獨財務系統產品透過介面或者資料池來進行互動，資料量較小時候透過介面，當有多個系統互動時候，使用一個獨立資料庫作為資料池。財務系統定期掃描資料池中資料表是否更新，如果更新財務系統根據識別符號讀取時採購訂單，還是銷售訂單還是其他什麼訂單；財務系統根據之前配置約定，生成對應的財務憑證，如果需要回寫憑證號回到業務訂單。

 

       而自開發財務系統可以採用兩種方式：

·        由財務系統建立憑證：財務系統獨立，當業務系統的訂單可以觸發財務憑證時候，業務系統傳遞財務憑證建立需要資料去財務系統元件，財務系統建立財務憑證並回寫到業務訂單，財務憑證資訊統一在財務系統資料表中記錄。

·        業務系統直接建立財務憑證：業務系統安裝自己系統中約定的財務憑證建立規則和財務憑證編碼，直接自行建立財務憑證，財務憑證在業務系統中建立。這樣的免去資料互動過程，但是財務憑證分攤在各個自系統，各個系統有自己獨立小賬套。在進行查詢和報表生成時候，財務系統要便利所有小賬套並集合。當然，現在很多財務系統也會把金額對應科目等核心資訊傳遞給財務系統，用於快速查詢和報表生成；詳細資訊則保持在業務系統自身。

 

·         核心內容：

o   業務系統的財務規範：涉及財務憑證產生的業務系統，可以產生的憑證型別，憑證編碼，各個事務可以觸發的借貸科目。這些都需要規範，有些可以在財務系統規範，有些在業務系統規範。定義號業務系統訂單和財務憑證的對映關係。

o   訂單流轉：業務系統中涉及財務憑證的業務訂單流轉，如果業務訂單流轉到可以生成財務憑證狀態；業務系統觸發生成財務憑證資訊；當訂單取消時候，也要出發財務憑證的沖銷。

下表列出一些常見訂單流轉和觸發財務憑證

系統	業務訂單	狀態	財務意義	對於財務憑證	備註
採購系統	採購訂單	貨物入庫		借：庫存 貸：GR/IR（暫估應付）
採購系統	採購訂單	收到供應商發票		借：GR/IR（暫估應付） 貸：應付賬款-供應商
財務系統	採購訂單	銷售單付款完成		借：應付賬款-供應商 貸：資金銀行存款	通常付款在財務系統處理，此處為銷售訂單回寫到業務系統，確認訂單完成。
銷售系統	銷售訂單	訂單取消		財務憑證迴轉	通常按照對應狀態，迴轉財務系統財務憑證
銷售系統	銷售訂單	貨物發出		借：銷售成本 貸：庫存
銷售系統	銷售訂單	給客戶開票		借：應收賬款 貸：銷售收入
財務系統	銷售訂單	客戶付款		借：銀行存款 貸：應收賬款	通常付款在財務系統處理，此處為銷售訂單回寫到業務系統，確認訂單完成。
OA系統	報銷單	審批透過		借：管理費用 or 銷售費用 貸：應付賬款-員工
OA系統	報銷單	付款完成		借：應付賬款-員工 貸：銀行	通常有財務系統處理，回寫到OA系統
生產系統	生產訂單	投入原材料		借：在製品 貸：原材料
生產系統	生產訂單	產生品出口		借：庫存-產成品 待：在製品	此處較為簡單描述
資產管理系統	採購資產	資產資本化日開始		借：固定資產價值 貸：應付賬款	假定透過採購獲得固定資產
資產管理系統	資產折舊	月末資產折舊執行		借：管理費用/銷售費用 貸：累計折舊	需要確保單個資產折舊金額之和，等於財務累計折舊金額
資產管理系統	資產報廢	確認資產報廢		借：資產處置損失 借：累計折舊 貸：固定資產價值	此處假定資產處置後，是損失

 

o   調查物件：各個業務部門中，操作業務系統的操作人員和經理。和對接財務人員。

o   調研關注點：業務訂單和財務憑證的對映關係邏輯；回傳邏輯；客戶/供應商/資產的財務資料表示等。

·        開發設計：在開發設計時候，可以安裝報表行財務系統建立報表行財務系統，然後考慮對外圍系統對接方法。首先要確定是財務系統進行財務憑證出局，還是業務系統可以出局財務憑證。然後是對於業務訂單對應的財務系統對映邏輯，觸發階段，回寫邏輯，迴轉規則。還有訂單多個合併一個財務憑證，或者一個訂單拆分為多個財務憑證的邏輯。同時各個業務系統也要考慮自己主資料的財務欄位加入等。

·        開發建議：以報表型財務系統為基礎。保持財務系統獨立性，同時要考慮的可以得複用性，介面穩定性，和訂單暴增堆積後，是否會出現在訂單為生產對於財務憑證問題。

o   以報表型財務系統為基礎；

o   以業務資料可傳遞財務資料到導線

o   定義自動觸發邏輯，對應產生的財務憑證的科目，借貸

o   如果回寫，回寫邏輯等

·        難點：

o   對映邏輯；拆分邏輯；訂單取消後，財務憑證迴轉；資料量極大後如何保證傳輸穩定。

o   中間狀態財務憑證：相對報表型財務系統中財務憑證是經過人工確認後輸入，自動憑證中很多是處於中間狀態，需要建立很多中間狀態科目，比如

·        庫存採購，採購品入庫金額不等於將來收到供應商發票金額，所以入庫產生的財務憑證中對應項為應付暫估；

·        生產產品，投入原材料，但是產成品還沒有完成，需要進入WIP在製品中；

·        給客戶提供服務，服務以及提供，但是沒有收到發票，收入只能計入收入計提等

這些中間科目，都必須按照期間，進行清空，轉移到確定科目。這些邏輯需要定義。

o   財務憑證回寫到業務系統：大多數情況，資料傳輸時有業務系統傳輸到財務系統，業務資料影響財務。但是也存在回寫的情況，主要一個是憑證號回寫，一個是財務憑證迴轉影響業務系統，中間邏輯需要進行考量。

o   稅務處理：稅務系統可以是一個獨立的系統，也可以整合到財務系統中。稅務系統由於其特殊性，在整合時候會涉及外網銷售系統，金稅系統，財務系統三方互聯。

·   進項稅：採購訂單生成時候，參照供應商、採購資訊和事前約定，確定稅率和可否抵扣。邏輯實現可以在採購系統，也可以在財務系統開發。那麼直接傳入進項稅金額和對應增值稅－進項稅科目，或者進入成本。

·   銷項稅：銷售訂單產生，安裝客戶、銷售資訊，確定稅率，此時傳入財務系統，生產貸：增值稅－應付銷項稅。但是開局發票需要從財務系統傳入到發票列印系統，根據客戶主資料，一般納稅人還是小規模納稅人，開局專用增值稅發票或者一般增值稅發票。而且發票號和開票資訊需要回傳到財務系統。而且該開票資訊還要回傳到銷售系統。

·   期末報稅：期末報稅需要申報表，包括銷售資訊，財務資訊，和開票資訊等很多資料，這些資料通常按照財務系統為核心，從各個分系統查詢後集合。

o   與銀行銀企互聯：財務系統和銀行系統互連，與金稅系統類似，付款，收款，資金池歸集的操作都要涉及與銀行進行資料互動

·   供應商付款：接到業務憑證傳來供應商發票，到達可付款日期後，財務系統提示需要付款；財務系統生成付款資訊，包括金額，付款物件等傳入銀企直連平臺付款；銀行返回付款成功資訊，財務系統產生貸：銀行 借：應付賬款的清賬憑證。並傳入採購系統。

·   客戶收款：定期查詢銀行金額，按照標誌位，收到客戶收款後，財務系統更新應收款清賬，並傳入銷售系統。

·   資金池歸集：與銀行商議，定期進行分子公司資金歸集處理，銀行完成後，傳入財務系統，產生對於財務憑證。

·        介面和擴充套件：

o   介面：已經說了很多，保證介面實施穩定反應及時。

o   資產管理/客戶/供應商主資料同步：當業務系統建立了主資料時候，有必要在財務系統建立對應的主資料資訊，方便進行財務視角的管理，如資產折舊慣例；客戶信用管理，供應商價格管理

o   多個賬套：考慮的基礎系統複雜性，通常不會實施多個獨立賬套進行多個公司管理，而是採用一個賬套加公司程式碼區別

o   多個會計準則：可以採用平行帳模式解決；實現是業務系統出發憑證是時候，根據不同對映規則，同時生成兩個憑證，寫入不同賬套。

o   集團公司報表合併：此處差別不大。

 

3、管理型財務系統開發

        傳統的財務系統主要目的是透過記錄日常財務憑證，生成提供給政府公眾的三大財務報表。而管理型財務系統則在完成政府報表出局這個要求後，更多關注透過財務系統，進行企業內部管理，最佳化運營，提升企業效益。

        而且由於財務系統相對於其他業務系統更為標準，更為嚴謹，可信度高，所以透過財務資料作為支援進行公司管理，比較合理。

        由於管理型財務系統需要於己於系統整合型財務系統之上，加上更多的資料和業務系統互動，所以對於實現比較好的管理型財務系統，必須是和業務系統緊密結合，甚至必須是一個緊密結合的系統。所以單個獨立的財務系統和外圍系統結合的方式比較難以滿足管理型財務系統要求，一個整體統一系統必須的。不論是自開發或者通用。

整合型財務系統的自開發和通用區別：

       現在能比較好實現管理型財務系統的通用系統都是多個功能元件一體的，比如銷售模組，採購模組等一起。而去要完善的訂單管理系統。通常來說即便是通用平臺也要透過大量的自開發或者定製增強，來時具體情況實現，某種意義上來到管理型財務系統，自開發和通用平臺功能上區別已經不大。更多情況時在海量資料情況下，自開發平臺因為底層實現的自主化，有更高的增強機會。

·        核心內容：

3.1 成本管理：

成本管理，其實是指目標就是把所有企業運營生產的成本，經過各個層級考核分析，從費用採購錄入，分配到部門，再透過部門服務方式，按照工時，產成品數量的因素，傳遞到業務部門的每筆銷售的銷售成本，生產部門的每件產品的產成品成本，和專案部門的專案成本上去。

成本管理可以實現查詢到某個部門，某個業務，某項專案的成本。給公司費用管理提供支援，同時可以為轉移定價提供基礎。

o   主資料：

·   成本中心：產生費用的單位，主要是部門，也可以是銷售門店，或者其他單位

·   費用類訂單：這裡包括內部生產訂單，給客戶銷售訂單，和專案訂單，透過費用都是最後轉入這些成本上去，並輸出到銷售。

o   分配邏輯－這裡用電費舉例

·   每月電費費用透過費用類財務憑證過帳形式進入系統，費用付款部門時財務部，作為費用第一級承擔部門

·   財務部按照對於後臺部門按照人數，對於生產部門按照機械工程數量，對於銷售部門按照銷售門面面積，這些指標，透過加權標準把電費分攤到各個部門。這裡要說明的事情分攤比例透過時按照期初管理部門討論確定的計劃定製的。

·   IT後臺部門按照填報給生產部門銷售部門的工作時間，把這些費用轉入到他所服務的生產和銷售部門中去，此時工時費用可以是電費和人工費，後臺部門裝置，場地租金等打包後的服務單位時間費用。如果沒有工時記錄的整體服務，公司整個網路維護，也可以按照受益部門門店安裝預先設立好的分攤規則，進行分攤；也可以按照生成部門或者銷售部門的產出品，反方向估算。

·   電費到了生產部門後，生產部門電費作為成本投入生產成本，加上後臺服務部門轉入的工時費用，和自己裝置折舊費，人工費，還有原材料費用，集合算出每月生產費用。按照生產訂單，除於每月產出品數量，計入到每一件產品成本。

·   轉移銷售部門後，銷售部門按照類似的比率，進行分割，結算到每一筆銷售中去，並按照銷售金額分配，算出單筆銷售的成本。

·   如果有些獨立的專案，比如某個獨立系統開發，可以作為一個部門這樣類似處理，不斷把投入費用進行計算，等出最後改系統的成本，如果內部使用可以轉為固定資產，如果銷售給客戶，可以做專案的成本。

           下圖作為舉例：但是並不是簡單三個層級，有些真對專案的採購，就一個層級，有些費用需要經過四五次分攤流轉。

輸入費用型別		第一次層級	按照各個標準進行分攤	第二層級	按照各個標準分攤	第三層級
固定資產折舊費用		採購部門	部門人數	IT部門	工作時間/或者分攤規則	銷售訂單
水電煤管理費用		財務部門	部門使用數量	生產部門	工作人員級別	生產訂單
房租場地費用		業務部門	費用採購時制定專案	銷售部門	銷售價格	專案訂單
人力成本				行政部門	產成品數量
生產裝置折舊費用
運輸費用
其他雜費

3.2 利潤分析：

相對於成本管理類似，利潤分析有是把運營獲得利潤，進行分析。和成本管理資料入口是費用，利潤分析的資料入庫是收入。

有兩大類分析方法，一個是按照各個維度和數量把利潤進行報表分析，第二是設立利潤中心，可以是銷售部門，也可以是某個產品類，甚至是某個後臺部門，對於每個利潤中心進行利潤考核。

o   主資料：利潤中心是考核利潤的指標，透過利潤中心

1.按照地區設定利潤中心

2.按照功能設定利潤中心

3.按照產品導向利潤中心

4.商業考慮設定利潤中心

o   利潤分析的典型案例：

              i.   獲利分析：首先，獲利分析是可以看做一個多維度表查詢，比如某個產品的利潤，某個門店的利潤。根據銷售訂單中的標記欄位進行分析。

之後可以看著標記欄位可以二次提取，比如銷售訂單裡面記錄了客戶資訊，客戶資訊包括了客戶的屬性欄位，在按照這些屬性欄位進行二級分析。

如果這些屬性欄位還有其他資訊，可以進行第三次分析級別。

輸入收入型別		分析維度（一級）	分析維度二級	對應金額
銷售收入		按照客戶型別	客戶中的屬性，如客戶是國有，海外還是個人
服務收入		按門店型別	按照門店資料進行二次分析，如實體店，會員店，專賣店等
其他收入		按銷售地區	安裝銷售地區
		按參與品牌	品牌資訊，品牌屬性等

透過這些分析，可以獲得

1. 單獨市場段貢獻 獲利分析

2.銷售單體的利潤目標

3.市場活動是否成功

4.收入和成本的構成  

 

              i.     利潤中心分析：就是透過利潤中心設定，把以前門店，部門，某類產品，甚至某個後臺部門如IT部門，做成一個獨立分析單元，分析這個部門的收入。如果該部門同時是成本中心時候，可以對於部門進行收入和成本分析。甚至可以按照部門為單位出具部門的資產負責表，損溢表等，當然需要進行一定的資料增強。

 

利潤中心分析還有個功能，就是提供轉移定價服務時候，提供評估基礎。

利潤中心採購資料舉例

利潤中心型別		收入	費用	備註
門店		銷售收入	由成本管理流入門店費用/門店資產折舊費用/門店人員人工費用
IT部門		提供給別的部門或專案服務工時	由成本管理流入部門費用/部門人工成本/人員費用	後臺部門有利潤統計方式有兩種，一個是按照填寫的服務工作時間*市場公允價格；第二是按照成本分攤規則回溯；業務部門把利潤反向分配給後臺部門
某類產品		該類產品銷售收入	該類產品生產費用/如果採購採購費用/運輸費用/銷售訂單其他雜費
某項研發		研發產品的銷售或者計入財務報表價值	投入研發專案的各個成本

3.3其他管理預測

 成本管理和利潤分析是現在財務系統主流的管理視角。對於自開發系統，完全可以透過調研公司管理層需求，對於透過可以財務系統進行管理和對未來預測。下面列出其他的透過財務系統進行管理和公司運營最佳化功能。

o   客戶信用管理：主要評估客戶信用，並且按照客戶信用在財務應付操作中對於銷售金額，付款優惠，可逾期時間進行定製等。評估標準是客戶過往付款逾期情況，如果信用沒有預期情況，可視為信用較高。

o   流動性管理：對於公司的可用資金進行管理，銷售訂單付款跳躍，採購訂單支付條約，工資支付時間，公司借款還款時間，定期利息，外借資金還款等等，推算出之後一段時間，公司需要支付的資金和收到資金，和沉積的分子公司的資金歸集。保證公司資金流動性穩定。

o   其他涉及財務的考核。

·        調查物件：於系統整合型財務系統調研各個部門操作人員，管理型需要於各個部門管理人員，公司管理人員，KPI制定者，還有各個業務線的管理進行討論。制定常見成本和利潤的分配方法，和歸集流程。

·        調研關注點：

o   管理準則和考核邏輯：因為是對公司內部管理，並不想普通財務實務有存在標準，更為自由。可以安裝財務的成本管理分析理論，和企業管理理論，企業ＫＰＩ體系的多個管理思路，結合財務可以提供挖掘的資料資訊，在於公司管理部門，部門管理層充分溝通商議，制定管理增強準則和考核邏輯。

·        成本管理：關注點在於成本分配分攤標準，成本分配分攤是單元設定，分配分攤週期，和結算到訂單，產品，專案的規則；

·        利潤分析：利潤分析的維度，分析表可以抓取的屬性，生產報表格式；利潤中心利潤統計方法等。

·        客戶信用管理：客戶信用分組標準，和不同級別信用對應財務處置

·        流動性管理：應收賬款，應付賬款的清賬時間，可能逾期機率；支付和接收金額的預估，按週期支付時間統計等

o   新增公司組織單元：由於是公司內部管理，常見的財務系統只有部門一些簡單的組織。沒有足夠組織單元來支援，需要針對不同需求，增加多組公司組織單元。

·        成本管理：成本中心，公司專案

·        利潤管理：利潤中心

o   新增考核和分析指標或引數：管理是透過指標或者引數實現，這些指標或者引數不單單要在財務系統定義，同時也要在業務系統中填入。只有這樣業務部門晚上這些指標和引數的數值，傳入財務系統，財務系統根據這些指標和引數。來進行分析。

·        工時，工作人數，費用比的

o   分攤和分配規則：一個從粗到細的靠譜系統，比如要求費用／利潤從粗分攤到細，每一級別的分配分攤，可能都要安裝上面的指標或者引數進行分配。

 

·        開發設計：

o   設計建議：

·        與財務系統保持隔絕：現在有些通用財務系統，在已有財務系統上進行管理實現，甚至在成本分攤過程中出發財務憑證。但是由於財務憑證設計法定報表出局，而管理功能大多針對內部，往往會出現大量沒有意義借貸科目相同的財務憑證。所以除了採購出發費用資料，收入觸發利潤資料，其他成本和利潤分配轉移不應該產生財務憑證；如果多個公司集團內部跨公司成本和利潤轉移，可以考慮安裝嚴格約束產生財務憑證。

·        新增多個組織單元，這些組織單元作為利潤和成本的歸結點；這些內部組織單元和公司架構保持分離；可以再不更改公司架構情況下更新考核單元

·        分配分攤運算元據準備：按週期執行：由於費用利潤很多資料，是需要進行分攤和分配，在執行分配分攤之前，為了保證分析資料完善，需要進行被各個分子系統資料統一。

·        報表設定：其實管理這麼多，主要體現就是報表，需要有很強大報表系統把分析出來的資料體現出來。建議此次透過API介面，由各個部門和使用人員，透過Python或者檢視化篩選，自行挑選需要資料。

·        開發建議：

o   開發基礎：對於自開發系統，強烈建議在系統整合系統已經穩定執行後，再進行管理型增強開發。如果直接進行管理型系統開發並不實際。

o   新增報表：儘量透過新增報表或者功能組的方式，而不是在已有系統表中新增欄位方式增強

o   報表自開發工具：對於由於大量報表存在，建議加入客戶可以直接使用簡單報表自定製工具。

·        難點：

o   主要難點：管理和分析的理論要求，如果資訊化，體現為可開發的系統

o   資料來源和歸集點：管理型系統主要對財務資料進行二次分析，這些資料來源要求清楚，歸集點和流程要通順，需要透過多次測試，避免中間斷鏈。

·        介面和擴充套件：

o   主資料擴充套件：如上文論

o   業務系統介面：需要大量資料傳輸，對介面要求增強

o   BI系統介面:由於很多資料分析，包含於過去年度對比，需要在資料倉儲或者BI系統讀取資料

o   報表匯出：和系統整合性類似

 

 

 

        總結，其實可以看出，財務系統自開發不是一步完成，通常是按照報表型、系統整合型、管理型逐步進化更新完成。當管理型實現後，下一步是透過大資料和財務歷史來對未來業務進行預測也是一個從要方向，還就是雲平臺推廣。這裡不做論述。