認識對象
    總帳管理模塊是 ERP 系統(tǒng)里的信息最下游, ERP 系統(tǒng)中, 多數(shù)的模塊信息最終會反映在總帳管理模塊!
    從逆向角度來看, 總帳管理模塊里的每一個科目, 都可以與上游的某個管理模塊(如果該模塊已被開發(fā)的話) 對應, 這就是 "總帳" 的意義!
    事實上, 許多 ERP 廠商也是從總帳管理模塊開始他們的故事!
   
    ERP 系統(tǒng)里, 上游的所有交易細節(jié)在進入總帳模塊時都會被約化, 只剩下少數(shù)概念上的信息: 科目, 預算, 傳票交易!
    "科目" 代表交易的原因, "預算" 是預定的交易, "傳票" 則代表實際的交易! 每個交易都有原因, 所以預算與傳票都是以科目做為依據(jù); 而且, 所有的系統(tǒng)輸出項目 (Output, 包含: 報表, 統(tǒng)計圖表, 查詢) 亦都以科目為依據(jù), 呈現(xiàn)出各種不同角度的結(jié)果!
   
    交易原因可以一直細究, 例如: 企業(yè)在 X 家銀行里存款, 而且在這些銀行各有 Y 組賬戶, 每個賬戶里可能有 Z 種幣別的存款!
    當每一種"原因" 都被賦予一個科目的編號后, 集合這些科目就可以形成枝繁葉茂的巨樹結(jié)構(gòu), 幾個類似的交易原因("科目") 可以總結(jié)為較為抽象的因素(父階科目), 而每個科目的交易(預算, 傳票) 也被納入其父階科目的交易統(tǒng)計!    
    
    肥胖并不健康
    在手工做帳時, 大抵會同時準備幾本賬冊, 當傳票窗體/ 預算數(shù)據(jù)確認后, 其交易數(shù)據(jù)會被額外登錄在各個科目的個別賬冊中(以下簡稱"過帳"), 其主要的目的在使科目交易的統(tǒng)計(以下簡稱"歸階") 分散在日常的作業(yè)時完成, 避免在查閱報表時耗費大量人工或時間去進行統(tǒng)計!
    在關(guān)系型數(shù)據(jù)庫被應用前, 多數(shù)的信息系統(tǒng)也會模仿手工作業(yè)的行為: 儲存交易, 并且過帳(異動相關(guān)賬冊內(nèi)容)!
    事實上, "過帳" 動作可視為交易數(shù)據(jù)被復制到幾份賬冊! 數(shù)據(jù)一旦被復制到兩處(以上) 的位置儲存, 即會衍生以下幾個問題:
    一. 難以分辨真?zhèn)? 不論手工做帳或者應用信息系統(tǒng), 在為數(shù)甚多的過帳動作中, 一丁點的人為失誤或程序錯誤(人難免失手, 馬難免失蹄), 就會造成窗體與相關(guān)報表之間無法勾稽, 而這些不吻合的差異并不容易厘清, 就像以下的 W 問句: 哪些數(shù)據(jù)是不正確的? 何時發(fā)生過帳錯誤? 什么原因造成數(shù)字不符? .....回答這些W 問句并不容易, 即使投入了大量資源!
    二. "信息不吻合" 的隱憂: 系統(tǒng)輸出項目的條件或范圍不一, 因此可能分別取用不同賬冊的內(nèi)容做為數(shù)據(jù)來源! 當不同位置的信息不一致時, 會導致這些輸出項目的結(jié)果也彼此矛盾, 毀及系統(tǒng)的可信任度!
    過帳的動作愈多, 發(fā)生失誤而造成信息不符的的可能性愈高! 因此, 我們可以將"過帳" 視為高風險性的操作!   
    
    瘦身的良藥妙方
    在關(guān)系型數(shù)據(jù)庫面世之后, 由于SQL 語法可以在相關(guān)數(shù)據(jù)之間產(chǎn)生關(guān)聯(lián), 并且迅速統(tǒng)計大量數(shù)據(jù), 這些能力合適地貼切過帳動作, 因此, 我們可以考慮嘗試舍棄"過帳" , 改采應用 SQL 語法實時統(tǒng)計交易數(shù)據(jù), 來達成總帳管理模塊里數(shù)據(jù)歸階的需求!
    如何以 SQL 語法實現(xiàn)交易數(shù)據(jù)的歸階呢? 在總帳管理模塊中, 有三份關(guān)鍵數(shù)據(jù), 包括: (a) 科目與父階科目之從屬數(shù)據(jù), (b) 交易數(shù)據(jù)(可能為傳票/ 預算/ 兩者皆有), 以及 (c) 統(tǒng)計過程中暫存的多維度資料!
    只要能夠撰寫精確的SQL 語法, 由科目階層的最末端(交易科目) 開始, 根據(jù)階層逐步統(tǒng)計交易數(shù)據(jù), 并且納入共同的父階科目, 再將之寫入暫存資料, 直到最高階科目(主科目) 為止! 這個過程包含兩層循環(huán), 內(nèi)層只需要比科目長度還少的循環(huán)次數(shù)即可完成! 下面是程序性的表達方式:
   
        ┌ 依次處理 (1)期初, (2)期前, (3)本期, (4)期末 不同時段
        │   1. 將指定條件內(nèi)的 (b)交易數(shù)據(jù)(傳票數(shù)據(jù)或預算) 寫入 (c)暫存資料
        │┌ 自 (a)交易科目起, 至主科目止
        ││ 2. 由 (c)暫存數(shù)據(jù)中統(tǒng)計科目交易數(shù)據(jù), 結(jié)合 (a)這些科目的父階科目后, 寫入 (c)暫存資料
        │└ 往上一階父階科目
        └ 處理次一時段    
    
    瘦得健康
    這個機制完全透過SQL 語法實現(xiàn)歸階, 因此, 靈活運用SQL 語法是歸階機制成功的必要條件!
   
    在實現(xiàn)以SQL 實時運算替代交易伴隨過帳之后, 只要付出幾秒鐘的成本, 執(zhí)行這個共享機制以完成交易數(shù)據(jù)的歸階, 即可以提供所有輸出項目一份統(tǒng)計后的完整科目交易信息! 這些輸出內(nèi)容由于全部根源自相同的歸階結(jié)果, 所以一定"表表相符" (除非SQL 語法有誤)! 此外, 只要將交易數(shù)據(jù)(傳票數(shù)據(jù)或預算) 稍加整合統(tǒng)計, 即可輕易地驗證這份歸階機制的結(jié)果!     
    
    有效的減肥
    對于許多已經(jīng)存在的總帳管理模塊而言, 如果經(jīng)常發(fā)生上述"總帳肥胖癥" 病征但仍束手無策的話, 改寫的負荷并不沉重!
    最重要的, 要先根據(jù)原有的數(shù)據(jù)表結(jié)構(gòu)與關(guān)聯(lián), 實現(xiàn)上述可以共享的歸階機制! 只要驗證歸階結(jié)果正確無誤后, 接著只需要在總帳管理模塊中所有的輸出項目內(nèi)改變數(shù)據(jù)來源, 轉(zhuǎn)而由歸階機制的結(jié)果(暫存數(shù)據(jù)表) 取出所需要的數(shù)據(jù), 然后就完成一套穩(wěn)定的總帳管理模塊了!
   
    最后, 您相信讓總帳管理模塊從"病懨懨" 變成窈窕健康真的可行嗎? 筆者確實實現(xiàn)了! 需要付出多少成本呢? 這就需要視您是否重視總帳管理模塊的問題了!

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標題：為ERP中的財務系統(tǒng)瘦身

本文網(wǎng)址：http://www.oesoe.com/html/consultation/1082065987.html