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

轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/

本文標題：為ERP中的財務系統瘦身

本文網址：http://www.guhuozai8.cn/html/consultation/1082065987.html