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